Apps App, Server & Database Setup, Start to Finish Advice?

[Robert Iannicca]

Sorry if this is a bit of an open ended question. I'm asking about the entire broad concept of building an app and running a database server, and how the two work in relation to each each other.

For years I've been interested in building apps and have read endless articles & success stories in Entrepreneur Magazine, which always go something like this:

"One day John Doe had his 'Aha' moment, and thought 'Why has no one else solved this?', so he built an app, raised funding, sold it to XYZ Comp, and now is a millionaire."

Ok... so that's a great story and all, and there's tons of them like it. But these stories do little to nothing to show what happens between A and Z. That is where my questions stems from.

Now, I happen to be a competent web developer, and I am highly familiar with HTML5, PHP, MySQL and running databases for things like ecommerce, Wordpress, forum systems etc (Even Xenforo forum such as is used here at the Android forums). I know the interaction between PHP code and pulling/sending information to a SQL database. But this is all web development - I don't know if/how this translates to the app realm.

So... based on peripheral knowledge, this is my theory on how I believe it works, and please correct me if wrong:

I assume an app can use one of the following methods (not mentioning others or combinations):

1. The app is rather complicated and/or mostly based on offline or real time use, without being tied to a central server or database for functionality (Some apps may not even need a database at all, and are end-user based on the device or can function autonomously). Here I'd imagine all the code, functionality, and data would be built into the app itself, sometimes even using an internal database system (I'm aware Android uses an internal SQLlite DB or something of that nature).
   
   
2. The app is primarily reliant on a database or web server, sends & receives data to display, and does not necessarily have data processing done in the app itself. Here I'd imagine everything is stored and performed on the web server, and the app acts merely as a shell to display that data upon request.

Again these are my assumptions. Now most of my app ideas would fall under #2, in which there would also be a website that would perform all the same functions as the app itself (the app would merely be an alternative to pulling up the website in a mobile browser - same functionality).

So using one concept for example - an app allows people to post local events in a city; yard sales, art shows, concerts, meetups, etc. These are stored in a web server database. Another user can then search by attributes such as Location, Time, Distance, Keywords/purpose, etc, and the system would display a list of events that match that criteria.

So using this example, again correct me if I am wrong, but I assume this would be done via the following (and you will see my web developer bias coming out here, this is what I'm trying to self-check against); A website and server database would be used, such as SQL or NGINX, and all the functionality would be built using PHP scripts to handle posting, processing, data retrieval and filtering to show results.

A mobile app would simply access these same DB and scripts, which would execute on the server, and communicate back to the app the results (the app wouldn't technically be "doing any work" other than communicating and displaying).

Is this somewhat correct, or totally off the mark?

Is the setup and relation between app, server and database always different according to the app's purpose? Is there a common setup?

Using the aforementioned example, would it be a safe statement to say that if the app or brand has a main website with all functionality done on the website itself (I.e. Craigslist.com but also has a Craiglist app, Match.com and it's Match app), then there's very little work needed for the app itself - wouldn't it just be remotely executing the same server scripts, and fetching the data?

There's dozens of major app/database setups and providers out there - how can one figure out the best setup to take?

How did John Doe and the countless others figure all this out when they just "went and made their app", did they learn, or raise funding and pay much more knowledgeable people to build all this? (Not that there's anything wrong with that).

Sorry for the lengthy writeup, as I've encountered very little specific discussion on this whole topic. It would be amazing to hear any feedback from developers who have gone through this whole process!

Thanks for reading,

 

[Deleted User]

Your assumptions are correct, and of your scenarios above, you'd be right in saying option #2 is what you are looking at, if your app ideas are predominantly server based.

The question of whether to implement an app, or simply use a web browser as a client, is really dependant on what the app needs to do. This debate has come up at my workplace. We develop a web application, and needed people to access it on mobile devices. We concluded that it was far easier to just develop mobile friendly versions of the web pages, rather than implement an app. Using a web browser means that your application has far more cross platform support i.e. all possible devices/platforms have some form of web browser, so you get the widest possible user base, with relatively minimal effort.

If on the other hand, you decide to go down the app route, you obviously need to support all possible Android versions out there (within reason), and possibly consider developing an iOS version. All this is an absolutely massive commitment, in terms of development effort, testing and ongoing support/maintenance.

What an app gives you is a very feature rich UI capability, which is probably superior to what you could implement using HTML and Javascript. An app can also integrate with local services, such as email. And if your app needs to run offline, then a local database can be used to give the user that capability. But then if you have a local database, it probably needs to sync up with the central server based database, and that can present problems.
Also if there is any significant data processing to be done by the client side, then an app can do that. A lot of apps which access a remote server utilise a 'REST' interface architecture, where data is obtained from the remote server, usually in JSON format. The app then does some processing with it, and presents it to the user in a nice UI. This differs from a web browser/server architecture, which involves HTML pages served over HTTP.

So for a traditional server based web application, an app does not really buy you much, if anything. In it's simplest form, an app communicating with a remote server will simply be a shell around a WebView (Android component for displaying web pages). Providing little more functionality than that. So you have to ask yourself, what's the point of using an app, why not just use the web browser as a client application?

Given your experience on server side web technologies, and that your ideas fall into category #2, I would ask the question, why are you even considering building an app? Would you be better focusing on developing mobile friendly web pages?

 

[Robert Iannicca]

Thank you LV for such a terrific and clear response!

Supposing taking the route of using WebView as you mentioned, and simply loading in a mobile-friendly interface, would this negate some of the version/platform complications? What you described about maintaining compatibility over different OS's and devices made perfect sense. Also, it sounds like using the REST method and WebView don't go together - one processes some data, the other none at all, is this correct? I'd imagine a WebView based app would have barely any substance to it at all.

This leads to asking, is there a catch of using dominantly WebView based apps as a go-to solution? It seems like with this route, any competent web developer could make a great app simply by building a functioning website and using the app as a shell to load the site. It almost seems too simple, or "hacky", to be a solid method (if not, that would definitely be amazing!)

Your question is also interesting concerning building an app vs a mobilized web page. My answer I suppose is just cultural; it seems apps (vs mobile pages) are all the rage now, and the whole app market has been exploding for a number of years. Especially with the newer tech generation and millennials, when people think of Snapchat, Whatsapp, LetItGo etc, I assume they don't access them via a mobile browser (or any former web-based companies), but jump to GooglePlay or the App Store. (Lately, even CNN.com has been pushing mobile web viewers over to the CNN app; Pinterest won't even let you use the mobile site anymore).

So perhaps clarifying more from an entrepreneurial sense - gaining user/market share, target base, valuations, while offering a unique service, apps seem like the way to go.

On the other side, I imagine that for business, clients, workflow, or internal systems like you described, using mobilized web applications is more appropriate. I recently built a Wordpress website for a client in the trucking repair industry, and we agreed offering an app (vs creating a responsive site layout) was fairly pointless - no one would really use it.

Again I'd look forward to any critique on these thoughts!

Thanks for the great info,

 

[Deleted User]

Supposing taking the route of using WebView as you mentioned, and simply loading in a mobile-friendly interface, would this negate some of the version/platform complications?

Do you mean an app which just includes a WebView? That is the worst case, because you have built an app which is just a simple wrapper. The app is now Android platform specific, and does nothing more than act as a shell for the WebView. You might as well just use a web browser.

Also, it sounds like using the REST method and WebView don't go together - one processes some data, the other none at all, is this correct? I'd imagine a WebView based app would have barely any substance to it at all.

The way we have used REST interfaces is to provide a service to a remote client, which needs to extract some data from our server side application. For example a network management centre might need to pull some information about alarms. We have that data in our server database, and can provide it via an exposed REST interface.
A WebView is an Android component which functions as a web browser within an app. So it is geared up for making HTTP requests to a remote web server, and receiving HTML pages.

This leads to asking, is there a catch of using dominantly WebView based apps as a go-to solution? It seems like with this route, any competent web developer could make a great app simply by building a functioning website and using the app as a shell to load the site. It almost seems too simple, or "hacky", to be a solid method (if not, that would definitely be amazing!)

If you already have a website developed, then I really don't see why you would go to the trouble of developing a WebView app, as opposed to simply using the web browser on the device. If the app's purpose is just to display the web pages, what's the point? You have effectively limited the website to working only on Android. And don't forget you *still* probably need to develop mobile-friendly web pages, because full screen websites probably won't work satisfactorily on a small screen. You may have to re-design the layouts, simplify the content. Our application's mobile web pages look nothing like the full screen desktop versions! Have you ever navigated to a website on your phone, where (for example) the dropdown choice boxes are microscopic and you have to constantly zoom and pan around the page to use it? That's a case where the provider simply serves up their standard full screen pages to any device. Annoying isn't it?
I don't know, maybe I'm missing something here. If so it would be interesting to get some other opinions on the subject.
Maybe companies figure that if they have to redesign their web pages anyway, they may as well go down the app route, and build a gorgeous native UI that looks fab on a mobile device.

Your question is also interesting concerning building an app vs a mobilized web page. My answer I suppose is just cultural; it seems apps (vs mobile pages) are all the rage now, and the whole app market has been exploding for a number of years. Especially with the newer tech generation and millennials, when people think of Snapchat, Whatsapp, LetItGo etc, I assume they don't access them via a mobile browser (or any former web-based companies), but jump to GooglePlay or the App Store. (Lately, even CNN.com has been pushing mobile web viewers over to the CNN app; Pinterest won't even let you use the mobile site anymore).

Ok, well maybe I am missing something then. It's true that the use of mobile device apps has grown tremendously. And probably these apps are doing a lot more than presenting a WebView. Snapchat is a bit different because it's a message app which integrates with the phone's cameras etc. You need local application code to do this. Whatsapp again, is a messaging service, but I notice they do also provide a website based version, in addition to the app. If you have a big enough dev team, you can cover all the bases, but we don't have enough resources to go down the app development route - I did offer my services!
In any case, I can tell you that the solution we chose is working great - the mobile friendly web pages look good on a small screen, and all possible phones out there can access our web application, including iPhones.

 

[Deleted User]

..And to throw in another option, there are cross-platform mobile app development solutions available, which claim to allow you to develop mobile apps in HTML/CSS etc, that work everywhere. e.g. Apache Cordova

https://cordova.apache.org/

Never used these frameworks though, so no idea how good they are.

 

[ac4android]

Hope you guys don't mind me joining the discussion.

What if dozens, hundreds of apps are feeding small bits of information into the database server continuously i.e. many thin clients (smartphones) uploading via https to a fat server ( can be MySQL or Oracle).

The app has a small footprint and I would use PHP at the server end.