Develop Reference

Django restframework API as a backend for offline first mobile app

I've just finished django app for multiple choice questions. However, I wanted to develop Ionic android app version of the web app. It's my first app and I am still learning web development. I'm not sure if Django RestFramework or firebase backend is more suitable for offline first app, particularly with respect to mostly text-based questions.

I suggest that you need to research the both options as there is a use case for each, but Django is not traditionally used for a mobile backend.
You need to weigh up the positive and negative of each and determine what suits your use case, at present you have not provided adequate information in order to make a determination either way.
Using Django as a backend is like saying you want to use WordPress as a backend, that is they are both content management systems that were not designed to serve as mobile backend Api's.
Additionally you need to consider the likelihood of your apps success, and what that means as a user count. If you feel that your app will be a success then don't waste your time with Django as you will very quickly have to spend money to scale the system.
The best option in general terms would be to use Firebase, a system specifically designed as mobile backend Api's.
However, to make an app like Uber, you’re going to require some custom server-side code. For example you’ll want real time updates of vehicle locations, availability, etc. This data can only be generated on the server since you’ll want multiple clients to access it at any given time. Firebase is probably too lightweight for this task, so making your own backend API would be a better option.

Xampp vs Firebase for large scale quiz app

I am creating an android quiz app, the core features of the app are
database user registration and login(registering a minimum of 100k users)
several databases(about 10) for different quiz categories holding about 500k+ questions in total to be retrieved by the user only when there is an internet connection on the android device
i need the app to be really secure as it would also be using credit card information
my question here is which would be better for the database,
using xampp(php, mysql and apache) or using google firebase? and why?
and is having 10 databases for 10 diffrent categories efficient, or can i have one database for the 10 categories?

1st. xampp is fully own your dedicated server, so you will need monitoring
and execute everytime whenever you need to do.Very need time for adding new feature next.
firebase is public server you can use free maintenance and troubleshoot. much feature their offer.push notif,authentification and etc.and it safe and secure for business.for further information you can visit firebase console site,
2nd. 10 database for 10 categories. it mean 1 database for 1 categories. you can call your database based your user request.
conclusion : it depending your technical skill and your exeperience to choosing an online service. if you try develop an app earn money. dont forget put an Ads space. so you can earn money for it.

Android App Engine with Cloud SQL or Datastore

I am new here and new to programming mobile applications for Android.
I am trying to build an app that has its user's log in info, and some other info stored in the cloud. The data will not be shared between client apps, but I need it to be available for a main computer to access it, if necessary.
I was wondering which service will be simpler to implement and use in this case: Cloud SQL or the Datastore API?
I read this thread (Deploying database on google cloud storage in Android application) and it was very helpful, but regarding my problem specifically, which service would be better?
My first though was that cloud SQL would be a better fit (but please tell me if I am wrong).
So I searched a little bit more about the service (https://developers.google.com/appengine/docs/java/cloud-sql/) and found the following sentence "An App Engine application must be in the same region (either EU or US) as a Google Cloud SQL instance to be authorized to access that Google Cloud SQL instance.". I think I don't fully understand how I can choose my App Engine Application region, but I am in South America, would that be a problem? I know that probably by default the cloud SQL will be in US... This thread is related to this topic: Using Google Cloud SQL with App Engine
Thank you very much for the help!

I don't think it really matters wheather you choose cloud sql or data store for simple user metadata management. Just bear in mind that app engine data store is no-SQL (think Cassandra) and CloudSQL is more or less managed MySQL service.
If you need to access the data from completely outside your app, CloudSQL would make more sense since all you need is access to the CloudSQL instance. If you do not need to access from outside the app (and you don't need your db to be ACID), then app engine datastore is advisable since it makes models and data handling more straight forward.
As for regions, if you start an app and you are a premiere customer ($$$$) you can choose to deploy the app in EU or US. If you're not a premiere customer, your app, by default, will be deployed in US servers. So, if you do decide to go the CloudSQL route, spin your instances in the US region, which is the default anyway.

SQL Lite Vs. SQLServer 2008R2

I have recently started working with Android. I decided to create a small personal android app for myself and my friends (anyone who wish to use it.) It’s a fitness tracking app where it’ll store number of sets and repetitions that you do for the day. Then, you can view your daily, weekly, or monthly progress. I have a WCF Web service that is communicating with SQL server database. However, I was wondering if will be better to use SQL Lite. I was thinking the app will be lighter using the web service, I could control the database, and I could even add more features that would allow folks to share their report with other friends. However, I have to host the web service, it will cost money, and if the service is down, the entire app is down.
Since I am a novice, I’d like to know what other cost/benefit that I should take into consideration?

If you don't want to host the database on your own server via a web service.
I think the easiest and cheapest method would be store the data in the embedded sqlite database which is local to the device. Then to ensure it is available on multiple devices, export the data from the database in some way, xml file, csv etc and upload this file to a cloud service such as drop box or Google Drive.
Then the app can use the file from Drive or Dropbox to sync the data into the local device database.

Start small and go big.
First implement it using sqlite on the phone and release it with adds or a paid version.
Once you see enough growth in fame and popularity and start seeing income, you can switch to the server, and go big.
I do not see any need to spend money on something which you yourself are not sure will be popular.
Also as you grow servers will start getting more expensive, and you will have to take into consideration emergency measures and such. That is why it is better to have something small and working and build upon it, rather than try something big and stop due to it taking up too much time or being costly.

Android application design using Amazon EC2 and SimpleDB

I'm currently developing my first Android application and still in the designing stage trying to come up with a solid model.
My application will use the GCal data from a users Google calendar and sync it up with one or more other users to determine common meeting times between all without the tedious back and forth of scheduling over email.
I vision this working by storing each user and their calendar data in a database that will be refreshed daily. When a query to determine the optimal meeting times between a group is issued, I want to select the calendar data of each user from the database, perform the computation to find optimal times, and display the results back to the user who made the query.
The AWS SDK for Android supports Amazon SimpleDB and S3, in which case I would use SimpleDB for my database. Where I am getting lost is using the Amazon EC2 web service in concert with the SimpleDB to perform the computation.
First off, any feedback on my approach and/or design is appreciated.
Second, how does using non-Android, but Java based APIs/SDKs effect applications, or is it even possible to do so?
The API typica for Java looks interesting and useful if it is possible to use with Android for instance.
Thanks!

So, I think its important to note a couple of things.
What you are describing is not an 'android application'. Its a web service application with an android client. The reason I'm being pedantic is that many of the design decisions you need to make are completely besides the fact that your primary client will run on android.
I'm concerned about the viability of storing the users calendar in a non-relation database. I don't know if you've already looked through this, but the problem you are trying to solve (calendaring) seems like it would benefit from the relational benefits of a relational database. For instance, i'm not sure how you would structure for storage the data of past, present and future events/meetings in a non-relational. Its probably possible, but i'm not sure if its optimal. Depending on the amount of data you may also need to consider the maximum record size.
While its true that AWS SDK for android supports writing to S3 or SimpleDB, I think there is a lot to consider. The reason you are confused about the interaction with EC2 is that normally, your EC2 web service will be interacting with S3 or SimpleDB. By using the AWS SDK you can, in theory, remove the requirement for a web service. My main issue with that is that you're now forced to do lots more on each client because there is no common access pattern. Your ios client or web client needs to have all the same logic that your android client has to make sure its accessing your s3 and simple db data the same. If that doesn't make sense i can elaborate.
Using non-android api's and sdks is a mixed bag. Sometimes it works fine if the classes compile to Davlik. If they don't it doesn't work.
One thing I might point out, since you'll already possibly be tied to a Google technology is Google App Engine. The nice part about it is that there is a free level of service which lets you get your app up and running without cost. Based on the technologies you are suggesting, it might be something for you to look into. Other than that, my other strong suggestion is that you focus on building out the web service first and independently of the android client. Take the time to model what the client server interaction would be and move as much of the 'logic' to the server as is possible. Thats what I felt like was missing from your initial description. Where the crunching would be.

my solution is that you use O-O principles. store your db on amazon dynamoDB and then sync user data with the mobile app. then you do processing of the data/computation on the device before displaying the results