We want to achieve simple but efficient system to post concurrent data from android application to rails server. The data sent [post] from multiple android devices, would be more than 300 at same time.
To achieve this, sidekiq could be best option. https://github.com/mperham/sidekiq/wiki/FAQ#how-do-i-push-a-job-to-sidekiq-without-ruby
I'm trying to post a data through android app to redis to process it asynchronously & then send it to rails application & database.
Does anyone know the exact procedure to achieve this ? Is it the best solution to handle requests asynchronously ?
handling the request asynchronously is usually done when you expect something slow to happen sometimes inside the request (like calling a 3rd party service). In your case, all you will do is insert a record into the database, so you don't really need to handle anything asynchronously unless you're going to use a distributed database system or something very complex. A normal SQL server will easily handle a few thousands of inserts per second (unless you have large and complex indexes affecting them), so this shouldn't be a problem at all.
Related
For better UX mobile apps store data on the client side (on the device) to provide immediate information when loading an app without having to wait for data from the internet and providing data even when the device is offline. Of course data is updated/fetched whenever possible later on.
I am building an app (in flutter) which is a social network/information feed like app: there are users, profiles, feed, posts etc. When the user opens the app I would like to show data that was available the last time the app ran.
My question is what is the right way to implement cache? There are two main ways I can think of, an easier/uncertain way and a more difficult/stable way, and I would like your opinion about them. I have time/resource constraints ofc. Most information is through HTTP requests, so:
The easier way: HTTP Cache interception
I would use an out-of-the-box cache plugin for my HTTP client. I think I can just cache the response for each request I make (for some time) and rely on the cached info. Images are also cached based on url. When I make a request on application load I return the cached result if there's any, and if it was a cache hit I fire the request again, so when you open the app you will see immediate information, but after a sec or so you will get the fresh data too. Usability of this solution ofc depends on how well I design my API.
Harder: Store data in a structured database.
This is the option I try to avoid, because it's more time implementing this. It could be either a SQL or document store, and I would have to implement the cache look up/save/update mechanism. Since I am just building the app, I think this would slow me down because data types/ architecture might still change. But is this the ultimate way to go with mobile side caching?
Thank you
I think the easier way is your best bet the only time i can think of that cache could be a problem is if you need critical data that has to be correct and not a old cache value, but you can avoid this problem by not caching the critical values.
Also if you use firebase it does some automatic caching which might be useful.
I am interested in making android app like crickbuzz that will fetch live content from server and also there is option of like and comment for users for feedback. So, can anyone tell that how to implement this i.e (how to fetch data from server) how that data will fit in app(confused about this how data get fit in instagram app means profile, home, search tab)
thanks
I suggest you check out this links
Android, PHP & MySQL
Fetch Data From Server
Ok, let's break it down:
The data is obtained from the server using http requests. It is usually received in the form of JSON String, basically a ordered, human-readable data format which is easy to read and parse.
On the app side, you need to implement the layout, which is done in xml and Java. You also need some logic which will obtain the data with the aforementioned requests, parse it, turn into Java Objects and put everything into the layout.
The process is not really complex, could be completed by a single person, but you will need experience, time and good architectural decisions.
If this is your first time with Android app programming, do some tutorials (especially ones that cover networking), learn some libraries (Volley, Retrofit, org.json, RXJava, Picasso will be really useful for what you ask about) and code several small apps from start to end. After that you may be ready to tackle the app you described :-)
i was trying to build an app which takes the data from server database and use it in android app ( in may case for reading the gprs coordinates available on database).
after a lot of search, i came across RESTfull services for implementing this. but there is a simpler way also, that is accessing the server database directly from android app by using a driver (jtds) and running mysql on server side.
i am actually confused which one to use. Why restful service which is highly platform independent and have a wide range or directly accessing the mysql database from server. which is most extensively used and why? giving below examples of both scenarios.
through restful service - http://avilyne.com/?p=105 and directly by accessing sql server database- http://amitku.wordpress.com/2011/08/03/how-to-connect-and-access-sql-database-server-from-android-app/
please let me know which is better and mostly used and why?
I would strongly encourage using the REST approach, and although there are many reasons, two or three come immediately to mind:
1.) Security. By using a REST approach, any data on the server side can only be accessed by server-side code, which can provide a protective layer between the data and the outside world.
2.) Scalability. A direct connection, such as the example at your link, hooks into a particular instance of a database. If that database already has a large number of connections, there will be performance issues or worse.
3.) Server side flexibility. If the underlying database structure or technology needs to change, a REST approach will allow for that. All the client side cares about is posting or requesting to a server that will respond via REST protocol.
I would think that a REST approach is much more widely used than a direct client-server approach.
I would ask a semi-theorical question about web services and client-server architecture.
I have a server with a database with about 50 tables. This server holds even one table which contains information about users associated with the clients.
Each client has associations with a subset of all data in db.
The defined architecture implies that each client (running on Android app) calling ,with a predefined frequency, a certain number of Web Services, fill the local database, creating a copy of all the tables residing on server sb, containing the only information related to the requesting client.
Furthermore, the data in db server side can change, so frequent synchronization is required.
Considering that the client application can be imaginated as a shop online application, so should be possible browsing through providers, articles, make a order,remove orders etc.
So, when I talk about fill the local database I mean store providers, articles, ...that is, all information realated to the requesting client.
Can make sense fill the local database with this information?
I think that is more reasonable call a web service only exactly when the information is required, and not store information in local db.
So, synchronization is no more required.
Tall me what you think about ? thank you.
I know NOTHING about Android development, but have tons of experience with using web services and SOA.
In my experience, especially when the client device has limited storage and processing power, all the business logic and data logic should be in the web services, and the client app used only for display and calling those services. How you implement that is something that we can't answer for you. It's different on every project.
The only exception is when you absolutely have to have the app running while not connected. In that case, be sure you know your specific requirements, and be very dilligent to only persist at the client the data that you absoutely need, and only provide the business logic that you absolutely need while disconnected.
(This helps to keep security simpler as well - lost or stolen devices are one of the highest sources of data breaches, so the less potentially sensitive data on the device the better.)
I don't know if that's helpful, but I throught I'd throw it out there.
If your application is going to work only online, then YES. You don't need to worry to store the data into the database and retrieve it later. If your requirement that needs to support both online and offline, then you have to go withe the database.
You can run a service or Async task or Handlers to invoke the Webservice from the Android Application, that way your UI thread won't be blocked.
If your response is too big, then probably you have to think about middle tier, that way you can convert the SOAP response to JSON that would be easier for the device to process the response and network transmission is faster.
I believe based on your requirements, its good enough to support only online mode... Because the data might vary if the user is not using the app for two days and logs in back and show offline data that might be irrelevant
I have a database and I need to present a data via HTTP using JSON web services. Currently, I'm designing JSON datasets that will be provided as web services. The data from the tables will be aggregated to suite an app needs.
If the data size is large and we will try to download that at once then it might take too much time and an app will not be responsive at start. That's bad. It's well known we should minimize the number of http requests the app will make to download the data. However if we would split the data into small chunks then during every app action step an app will performe http requests and that might be unresponsive solution too.
We are talking here about mobile app development, so internet will be exposed over cellular ISP or wifi, so the speed might be quite slow. I understand the split process depends on app workflow process and etc., just curious are there any general guidelines? For example: if JSON data is larger than 1MB then definitely split it into smaller chunks...
Look at how your mail read work. You probably have tens of thousands of emails in your account. The app will show the first ones then provide a button at the bottom of the list to display more items. It's a pretty good solution usually to provide a lot of data.
Also #Selvin ideas are just great. Don't use UI thread to download stuff, use a different thread. Services are pretty good for getting data asynchronously.
One of the way is to create a service which gets started when there is network. All downloaded data can be cached in sqlite and use a content provider to get the data. But it depends on your app.
Sometimes it depends on your UI Screen. For eg. You can create a Listview with load more. On click of it load extra data.
Other way is to create API such as which gives only updates based on timestamp. But its all depends on the app. Just sharing my ideas. Might not be perfect. Others can surely give a better one.