I'm here to discuss about different ways to handle an Android application that can point its APIs to a server A (ie. httq://a.myproduct.com/api/...) for the client A, or an other server B (ie. httq.://b.myproduct.com/api/...) for another client B.
What i do actually is to generate different APK of the same app for each client. This solution is okay for one or two client, but will become quite heavy to deal with later..
I'm trying to find a better way to have one unique APK which can work with different server url.
Another constraint is that on a same device, i can have an app that talk to server A and an other app that talk to server B.
Here are the solution I came up with :
Keep going with multiple APK...
Have a "central" server that each app calls the first time to know with which server it has to talk and that store that in shared preferences.
Have a file store somewhere that make the link between an app and a server
for example:
com.mycompany.productA:httq://a.mycloud.com
com.mycompany.productB:httq://b.mycloud.com
But how to handle this file ? What is creating it ?
Use Android account system ? Create an account for each cloud ? I don't really know..
Does anyone, already experienced this ?
Considering you are able to map connecting devices IMEI to clients, I will briefly give you pros and cons of the three methods you mentioned.
Multiple APK's
Fully isolating client from other knowledge - safe
Not scalable and maintainable (issuing updates if needed).
Central Server
Scalable, easy to update information (in case you change a.mycloud.com to a2.mycloud.com)
Not as robust. What if server goes down? Possible attacks, or bugs to worry about.
All URLs embedded into APK
Stable and does not have large overhead in time/resources spent of your team.
Insecure, you should assume people having access to APK will have access to the file mapping IMEI's to companies.
If client's IMEI data or company url's is sensitive data, then a big no-no.
Are you a large company? If yes, then you are probably having production servers already and could go with second method.
I guess you can build a generic app and use some sort of auth system on the client app. For example, if the user identifies himself as "Client A", your web-service can "tell" your app to use the first endpoint. If it's "Client B", then it will be second endpoint. Bottom line is: make your users sign-in and then use credentials to distinguish the users.
Related
I need to develop an Android app which is basically a geolocator, allowing people to reach each other via Google maps. All being said, I don't know how do I accomplish such thing since I don't know how it does work and if I need a server or database on the way. I'd be grateful if anyone could shed some light on this topic.
As you said you will need Android application and Server through which Android clients will communicate.
Android Application
will be getting data of other Android devices from server and then showing those data on the screen
will be periodically sending own location to the server
Server
is responsible for storing geolocation of Android clients, data can be stored in some database or memory of the server, depends on the use case, how long you need to have those data, how important they are, etc.
is responsible for sending stored geolocation data to Android clients
you have various options, you can write your own server in whatever technology you wish - it can be PHP server, NodeJS server, Java server... or you will use some serverless solution. Check for example
https://firebase.google.com
has to be hosted somewhere, you have many options:
there are "traditional" hosting providers, where you are usually limited by technologies you can use, for example you can just use PHP or you will use products from Heroku or Amazon AWS.. there is more, Microsoft has Microsoft Azure or Redhat has Openshift.. There are differences in prices, services, etc., it is up to you to look and decide what is the best for you.
I for sure missed lot of things. It is not in my power to describe every possible corner case because the question is too broad but rather provide you with higher overview of the problem and possibly point you where to go next. I suggest to you to read more about problematic and then get back with more specific issues to solve.
I have been searching for a proper answer to this question, have a bit of background in front end development, but with new concepts like SaaS, PaaS, etc. want to get information from experts out there, that could help any newbie to understand what it's all about.
Say I am trying to develop eBay like an app that takes a product from a user and sells it back to the other user who needs it.
Will my app need a backend server? If so why? I am already uploading my app to Google Play Store or Apple Store.
How will the backend server like HEROKU or FIREBASE or AWS help my app?
Can I implement two different services in single app, say for eg., firebase for backend database and HEROKU for payment processing?
Thanks again for your time and information.
SaaS
Answer: SaaS stands for "Software as a Service". In layman's terms, someone developed some software and hosted it somewhere. You can use that hosted software in your software project/product as a third party service (like public API); or directly use that as individual software under some license like Firebase as mentioned.
PaaS
Answer PaaS stands for "Platform as a Service". In layman's terms, someone configured some hardware and exposed the hardware controls via some web based application or REST APIs. You can use that hardware to deploy/run/manage your application without having the actual hardware on premises.
Backend Server
Answer First of all, let me explain the server. The server is a middle-man who serves whatever is requested of it, and all browsers/mobile apps act as client. So for example, the web is all about client-server communication.
So taking the example you mentioned, an eBay-like app takes a product from a user (client action) and puts it on the server (client requests in background for server to put product on server). Then another user opens the app (client action) and searches for the product (mobile client requests server to return that product, if valid and matching search criteria), and then he can buy it (mobile client will request server to complete the purchase).
You have to understand that for any communication between web application, mobile application or desktop application, there will always be a server. Even in file sharing applications like shareit, one mobile app works as server and same mobile app elsewhere works as client.
Yes, backend servers like Heroku or Firebase or AWS will help your app to complete your application business flow.
Yes, you can implement two different services in single app, say for example, Firebase for backend database and Heroku for payment processing or hosting your application/APIs.
Unless you are experienced with building distributed applications that can persist data across multiple nodes in a consistent manner, and ensure data available, I'd say you most definitely need some kind of backend. Unless of course you only plan to have user-to-user transactions, that can rely on direct messaging between client applications - which seems pretty pointless and quite far from the requirements of an EBAY-like product.
In terms of the architecture, you can follow many different approaches, but in most of them you will require some sort of data access layer. I'd recommend looking into the three-tier software design pattern (https://en.wikipedia.org/wiki/Multitier_architecture) to better understand the way this type of software product is typically designed.
After sorting out which type of data persistence you prefer, you'll need to setup the backend where your mobile app will connect to retrieve the data from (things like products being sold, user profiles and ratings, your own history). Of course you could also connect directly to the database from the app, but that would be a big mistake - it would meaning making the DB access publicly available, and thus exposed to attack, not to mention that you would be hard-pressed to find a solution for user registration and authentication, which would have to be provided by other means anyway. Typically your backend will also manage user registration and authorisation.
Heroku, Firebase and AWS are all very different, each with their strengths and weaknesses, but there's nothing like trying them out to see what fits best. What you refer to as "Google Server" and "Apple Server" sounds like a misconception, and you probably mean the Google Play Store and the Apple Store. These are not applicational servers that you can use as a backend, and serve only as a repository for your mobile app from where users can download it, and nothing else.
Without some sort of backend mechanism, the challenge of making data available for the consumption of multiple users would be overwhelming.
I know this isn't a very specific answer, but your question is quite broad-reaching, and it seems you need to look into some basic fundaments of software engineering before going into more detail.
I am taking a drive into GTFS (and only a couple months into learning Android coding). I signed up as a Developer for my transit system and received a key for their GTFS data download.
However, they require that you download the GTFS data to your own servers rather than pointing your Android App directly to their servers to get the feed. Basically, I need to accomplish the below.
Their Servers ---Data---> My Server ---Data---> My App
My app will have all the tools to read/manipulate the data so the My Server part should do nothing to change the data.
I've looked into services like Amazon Web Services which has a free tier but not sure if that is what I need. Also, if it is what I need, then unsure of how to tell it to get/store the data from the transit system's servers.
Appreciate any help!
One of the easiest ways to get started, if you want to host your own server, is to use node-gtfs. However it is not the only way.
The shortest learning curve would be to use one of the two services that host transit data and provide APIs that you can use to build your own app:
Transitland
TransitFeeds.com
There are also a number of other libraries/tools/servers in other programming languages (depending on what you are comfortable with and what your goals are). OneBusAway is probably the most robust but unlikely to run on the AWS free tier. A good list of the others can be found here.
I am developing a voting application based on Android. This app will be used to create user accounts, receive notifications and caste vote.
I want to develop a back-end server for this application which will also have an Administrator interface to create new voting events. I want to know what all options I have to implement this project.
The server must maintain user account records in a secure manner, send out one-time-passwords from email, have sessions implemented for users logging in from the Android App, send out notifications about upcoming events to the app.
What back-end technology, database, parsing(for communication between server and android application), encryption(for secure communication) should I use to make this possible?
I also want to know how would I be able to host this server, both on a local virtual machine as well as on an online hosting.
The scope of your project is far too large if you're wanting sessions, administration views, E-mail integration, encryption, etc., without even knowing how it would all interact, or even what language to use.
As for what languages / services you would need, it varies for each task:
For administration views, you're probably looking at either ASP.NET or PHP with a CMS.
In terms of security, you'd want either MySQLi, or preferably, PDO. Make sure to read up on how to prevent things like LFI, RFI, SQLi, and XSS if you want semi-decent security.
Both ASP.NET and PHP can handle sessions, and they're fairly easy to understand in either language, so that wouldn't be too much of a concern.
While you can send out E-mails directly using scripts like PHP's mail() function, you probably want a system that can easily monitor things like how often users click on certain links, where the people who click the links are located, what campaigns are most effective, etc. For that, you'd want a service like MailChimp, Marketo, or Pardot.
As for how to have the back-end interact with the front-end, you're working with Android, so you're probably working with Java. That means you would be limited to functions like HttpMethod. Having said that, you can create plain HTML applications, or use a service like PhoneGap. In either of those situations, you have AJAX at your disposal, which will make things a lot easier.
For hosting, simply do a Google search for 'web hosting service'. There's literally thousands of decent hosts. Some have better pricing than others, but some have better features. I can't really recommend any brilliant ones, as they all meet different needs. To host locally, you'll want either IIS, or WAMP / LAMP depending on whether you are running Windows or Linux.
If you're not familiar with almost every term that I've mentioned, then the scope of your project is too large, and you'll definitely want to scale back.
I don't mean to scare you off, just making sure you're aware of just how difficult it would be to put all of that together :)
I'm looking for suggestions for ways to share Android app data between phones running the same app. For example, lets say I have an app that stores a database of book reviews. If person A has a book review that person B doesn't have, what are the options for getting that information from person A's phone to person B's phone?
Currently, I'm aware of the following options:
- Upload data from person A's phone to a server, then download data from server to Person B's phone.
- Write code to have the phones sync up using bluetooth
- Write code to send SMS messages
I'm wondering if there are any more options besides these, and if there's actually a best-practice for accomplishing this?
Ideally, I want the users to simply click a button in the app to make the sharing take place, so I don't want to go down the bluetooth route because that requires the user to do a bit of setup (or assumes they already have set things up in the form of bluetooth settings).
Since the data can be of variable length and potentially large, I believe that would rule out text messaging.
As far as the server route goes, from what I understand this seems to be an ok way of doing things, but my problem is that I have no experience with having users potentially sign in to a server and then uploading data. I don't know of the cost concerns (if any), or of potential security concerns (allowing just anyone to upload data, I'm not sure if I would have to take steps to ensure someone couldn't bypass the app and upload malicious data).
So, can you guys give me suggestions and point me in the right direction? Thanks.
I'm wondering if there are any more options besides these
You could try generating a QR code and scanning it on the other phone. Beyond that, I think you have it mostly covered.
and if there's actually a best-practice for accomplishing this?
That is impossible to answer in the abstract.
Keep the database server side and interface with it via a web service
I too am looking for a solution to this very problem. I'll throw it out there that a fourth, or rather extension of your first option, is to use the Cloud to Device Messaging Framework, though it still requires (as best I can tell) having your own server, though I suppose you wouldn't need to store the database server-side longer than it takes to send the message, provided you keep it under 1024b (or whatever the actual size is).
I don't believe there is a convenient way to monitor/send email in the background. If I could have my app monitor email messages looking for a key subject, then parsing the body, I could probably accomplish what I'm looking for using email as the transport.
The problem with maintaining a server, is that you probably would need to build in a subscription fee to your app to cover the costs of maintaining a server, as one time sales may not be able to cover the ongoing expense.