Firstly, great that you are learning more about DApps, it's always great to see the community growing. However, you do have some misunderstanding about the way the DApps should be designed, so I'll try to point you in the helpful direction.
Technology Used: Ruby on Rails (Back-End), React (Front end), Solidity(Smart Contract)
As pointed in this answer:
A DApp has its backend code running on a decentralized peer-to-peer
network.
DApps by definition don't have classic backend, like the RoR would be. That means, in order for your application to be called DApp, the smart contracts should contain all your backend logic. The frontend could be any JavaScript, really, along with the web3 library that gives you the APIs to communicate with the smart contract backend.
This is a completely different paradigm, which I had problems wrapping my head around for quite some time. There are decentralized alternatives for some of the classic technologies, such as IPFS or Swarm for storage or hosting your DApp website on, "users" should be tied to blockchain addresses, you could use PouchDB, etc. The DApp should be fully open-source and autonomous.
If you wish to build the betting DApp, you really don't need to store user information in database - you can program the frontend and, for example, interact through the contract which sends the % of any bet to contract in your control and have sound business model while providing good service DApp users. But if you want each bet on blockchain, the transaction costs would sometimes prove too high. However, this doesn't mean that you can't have hybrid app - true DApps in their current state do have some limitations.
Working on Lemon Email, we had to weigh some of the benefits of the established technologies (SMTP server for example) along with the benefits of decentralized applications - so we decided to create the DApp to suit everyone. We used the Ethereum Blockchain to store metadata of our interactions, and IPFS as our storage. If you wish, you can read more about our architecture here.
Some additional reading:
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://ethereum.org/dao
https://www.packtpub.com/big-data-and-business-intelligence/mastering-blockchain
Web3j documentation explains most of the things. I found this android ethereum wallet created using web3j. Might help you. https://github.com/matthiaszimmermann/ethereum-paper-wallet
Alternate:
I would recommend cross-compiled go-ethereum for Android. This is a light client for mobile devices and does not require you to download the entire blockchain. After importing maven dependency for the same you will get an API to interact with the blockchain (example program). You can create new account, check balances and send transactions.
The only thing is that Android API is not documented hence it is difficult to work with it. I hope the developers would do something about it in the future.
Updated:
Ethereum don't have have an Android API till now, but auto complete tools in IntelliJ or Android Studio will help you. You can refer to the following code to get a little understanding of the API.
Ethereum creates a keystore file whenever you create a new account which is something like this:
{"address":"bab565b65fede.....7a98ab7c330c","crypto":{"cipher":"aes-128-ctr","ciphertext":"ab4913efa82.......d3d5fe335025596","cipherparams":{"iv":"ece5ac32........4942b58"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"bcd244b8ee3def42........0d4c78758d858d3502"},"mac":"1c618efa10d54......3f5a3e4377"},"id":"0e0416d0-2a58-43c9-86cc-2c1eaa11957b","version":3}
Where "address" is your wallet address and "crypto" constains your private key enctypted with a passphase. So ethereum will help you manage user accounts, you just have to create a mapping between usernames and wallet addresses.
Best Answer
If you store keys and password anywhere else than on the users device then you are back to square one, should stop right here, go back to using a traditional webservice and payment integration using Stripe or alike.
A secure way to go, is to implement a hardware wallet such as this one or this one. Geth can interface them and they also come with APIs that your custom app could use to request the hardware device to sign a tx. This is the ultimately secure way and best practice.
Now I read from your question that you are concerned about usability and convenience (e.g. "lost key" scenario). It is generally hard to find a golden middle between security and convenience and there is not one solution that fits all needs. Do you administer millions? Then you want to go via a hardware wallet without exceptions. Do you just control a few cents or a funny game? Then you might be fine with an in-app or mobile wallet. Do you actually need a blockchain in the first place or is a centralized legacy solution the way forward because you do not need to guarantee that people can interact with your dapp disregarding of your existence?
If you need something reasonably secure and want to go via hardware wallet but also treat a lost key scenario somewhat gracefully, you might setup a smart contract that provides e.g. a (secure!) web of trust. e.g. once 3 of my 5 trusted friends confirm that this new account X is actually me, and my old account Y is indeed lost, then they can transfer ownership of all assets from Y to X. This along with a time-lock and some emergency off-switches is starting to be the really interesting side of smart contracts, see e.g. the discussion here.