Curious what people think about the number of screens in an app. At what point should you start considering creating screens via php etc. rather than the control panel? Is at 500, 1000, 100,000?

When I first started creating apps, it was with a site called iBuildApp. You would click here and there within a browser, a voila!, after a couple of days, you would have your app, ready to submit to the stores. When I found Buzztouch, it was interesting, but not terribly productive. About a year later, it became usable to the extent that it looked like iBuildApp; click here and there, and you would have your own app. Creating apps with Buzztouch looked more like working with Joomla than with WordPress (this will mean a lot to those who come from Internet to the creation of apps). Lots of parts were missing, such as reading player lists from YouTube, reading RSS feeds etc (only recently have these become available for the Android, for instance) and creating an app lasted approximately 5 to 7 days (for me). (That is starting from the already made content.) Soon I noticed that many parts of the apps were identical, so I started using JSON Snippet Keeper and it worked for a while. I left it to start creating apps right from PHP (I am into programming since 1976.) and it really helped, to the extent that one day I created three Android apps in one day. They were not terribly complicated in the programming sense of the word, but still hundreds and thousands of people all over the world liked them as they were. So, if you know PHP and SQL, my advice to you would be to start using them right away to create apps on the fly. For example, my apps contain a main menu option which says "look, we have other apps in the store, would you please take a look?" The first several apps, I had to change the list of existing apps in the Play store manually, and then resubmit them... lots of work, little gain. So I created a PHP script (written in CakePHP), in which I add an app once to the server data, and all apps that are already in the store, read the current data and show the new app too. The actual number of screens (100, 100000 or whatever) does not matter. As soon as you convert app making from clicking forever in the Buzztouch control panel to text editing in JSON, you will be able to make lots of apps, faster and more consistent than before. On the other hand, if you are making a game, or some kind of very specialized software, PHP and server side data may not be that important.

Unlike Dusko, I rarely make 'totally' dynamic apps. In my region, cellular data costs, so 'offline' is far preferable to 'online'. That said, I completely agree with Dusko. Even though my apps are 'offline' (usually), I create numerous childItem files as saved text files, generated via php and mySql. So for me, it really doesn't matter how many screens you have, or the use that you intend. Getting some php/mysql under your belt is a pretty wide solution to a number of challenges. And 'my' idea of 'too many screens' usually begins when you have more than one of a kind. And *anything* will childItems, even static, can benefit from an external file. And it's not like you 'cant' create an app with thousands of screens, you can. But it's just not efficient. Either dish it up dynamically or create custom childItem files to include in your bundle, either decision works well with php/mysql. It takes an extra minute to setup, but the return comes with scalability and portability. You can grow to huge proportions without jeopardizing your app framework, and if you need to recreate the same thing in a different project, it's practically already done. Not that long ago I released a package of Susan's php/mysql scripts that you might be interested in. The post concerning it is here: http://www.buzztouch.com/forum/thread.php?tid=DD7AB5D535F2631073ED32C&currentPage=5 Cheers! -- Smug

Smug's LoadScreenObject kit is marvelous! Be sure to explore it for loading data into screens from a remote source. Instead of creating screens in the BT Control Panel, I create the screens as individual JSON .txt files by hand. That allows me to setup a template file to rapidly and semi-automatically create each screen's file. Then I simply add those files into the package for use in offline mode. dataURL is the means to fetch those screen files from a remote source. Then one must be online. -- Niraj

David Book talked about this at Code Camp a bit. After you get beyond a certain number of screens (maybe a few hundred?), it is much faster to load them on a dataURL, unless you have a compelling reason to keep the content offline. Another factor is the evolution of coding skills. When a new users first start this, they may be locked into the control panel. Then as their confidence and skills grow, they move on to better ways to manage app data. The control panel is a slow way to enter screen data--much faster to upload a data file into mySql.

As always when you post something you get great answers/feedback thank you all. What I am thinking of is how I could have a list menu with for example Car Dealerships that when you pressed a dealership name would load another menu list with specific screens for that that dealer (maybe Directions, Gallery, Call/Email buttons etc.) I have created a php/sql script that does all of this in in html but I really wanted to use the actual screens available in buzztouch. Thanks again! Magnus

removed

I keep the number of screens in my Map App to a low number at any one point in time, because of the scenario that most users will be in at the time they are using my App. One screen lists the countries included in the App. The next screen, the cities in the country. (The USA version has a screen for the 52 States, DC and Puerto Rico.) The next screen has a short list of categories the location fits into. The final screen is the Map with marker pins. It is a Map App, therefore customers will be using it for directions. Not in the comfort of their office because they will be traveling, not necessarily in the comfort of their Hotel room because they will be out exploring, but more realistically on a street corner in a new city, in broad daylight, or maybe after dark. No time to wade through endless menus (screens) to get to sub menus (screens)! They want to see the Map, with locations (marker pins), their current location pulsing dot, and at the most, optional driving (walking, bus, train) directions. The second aspect of the number of screens, for me, is the total number of screens in the Map App. That is why I have actually 12 versions of my App, divided into the 12 world regions. If you are a non-EU citizen going to "Europe," you are actually going to the "Schengen Territory," which is about 26 countries (and growing). Therefore, that is one world travel region for me, with one Visa requirement. As a purchaser of Apps, free or paid, I'm not looking for big Apps that have a lot of size, menu options, tabs, screens. I'm looking for productive Apps that get a few things done, really well. When I'm using my iPhone or iPad, I'm not using my desktop; I have a smaller screen, I need to "click" with my fingers, and I'm arranging the order of my Apps by the specific, very specific, task(s) each perform.

52 States? Cheers! -- Smug

52 = States + DC + Puerto Rico.

@Magnus -- for that Dealership scenario, loadScreenObject is you friend. As Smug said: - my original loadScreenObject playkit is still available here: https://dl.dropboxusercontent.com/u/115208762/loadScreenObject.zip Read this for an explanation from David Book and Smug: http://www.buzztouch.com/forum/thread.php?tid=0AEFF1909A28E9AC27DD126 -- Niraj

Thanks Niraj reading about that now, Smug's play kit also looks interesting!