I am planning to create a mobile app (android). It has several pages/frames for different cases. Now the number of frames/pages that I would like the app to have would grow over time, so new frames/pages would keep on adding.
Now, I have two options the way I see it. One being keep on adding new version of the app with new pages/frames once every few months. Other being I decide upfront all the possible templates for those frames. Once the templates are fixed, the response (from REST API containing data to display) would also contain the information of which template to use. I could embed the logic on how to interpret the template type available in response in the app code, so the app knows how to display a template of type "table" and what constitutes the table headers, etc.
The caveat for former approach (upgrade) is that once in while, app needs to be upgraded, something which not all users would like to do. A way around it is to enforce an upgrade, which renders app unusable. The problem with the latter approach (template) is that a lot more code needs to be written to make it work right.
I would like to know what approach is mostly used, and whether there are popular apps out there which use the latter (template) approach.
I definitely recommend using the first approach (that is, you submit updates when you actually provide new versions of the app...).
Here are a few reasons which seem to be enough to choose the regular option:
If you use the templates, you are "forcing" updates to the user. One day he has a UI, and the next he has another one (new element in the menu, or new display of a known activity/fragment). And that's worse, because he didn't receive a notification that there was a new version of the app. So he might actually get confused.
You are relying on a web connection to perform this check. So you don't even get the guarantee that this will work (depending on the permissions and business of your app, this argument may be invalid for your particular case. I wanted to answer to the general question though).
You will add a ton of complexity to your application's code (meaning no offense, I doubt you can think up-front about ALL the designs/renderings you will need in the coming months/years). And a higher complexity = more bugs, statistically.
Do you realize that the second approach you are talking about is more or less the principle of a website? Maybe what you are looking for is a simple app which has a webview to your mobile website?
Related
What are some compulsory test you need to carryout on your application before it goes into production?
If I understood you correctly, you are wondering what exactly you need to test before users see your application?
For me it is divided into two steps: Logic and UI.
Regarding the ui, you need to make sure that your application looks good on different screens and devices, that animations work correctly and views do not lose their positions ...etc
Regarding the logic, everything is a little more complicated, we write scripts to understand if the user will have difficulties with the application. For example, are errors displayed correctly if we receive them, does the application work offline and what exactly is available, do our functions and queries return what we want to get from them, and if not, again, do we inform the user about this.
Maybe if you tell us more about the specification of your application, we can help you even more.
So I am in need of some assistance in trying to determine what I am going to need in order to accomplish a task.
Plain and simple...I am looking at accessing multiple databases some of which may contain over 10,000 records via Android. From what I have seen web services that return JSON is the way to go for something of this nature, but I don't think that fully answers my question or know if this is the preferred way to go about this.
Digging a bit deeper...I have a few apps on the market now, but this will be my first attempt at an enterprise style app, and I have accessed public web services with a lot smaller footprint than what this is going to be. I have little to no experience within the realm of server/network administration which is where I am getting tripped up. This is from the ground up and I have to ability to obtain almost any resources I need to complete this task.
It appears that there is a SQL Server 2008 on the back end if that helps. If I need to provide further details let me know. I am looking at a solution that will handle organizational growth, scalability, authentication and ease of user...so keep that in mind too.
So what is the best practice/preferred method for doing an enterprise application with a substantial data set? What are the big dogs doing, and how? Both on the client side and server side. I am trying not to "screw the pooch" out of the gates on this, and this is one of those measure twice and cut once situations which is why I am trying to garner plenty of input and assistance.
Thanks in advance!
If you don't have an API/service yet, you need to write one on top of your database.
I can think of two approaches, depending upon your use case.
Paging: Setup an API that supports paging, and show the results page by page. The user can't possibly view 10000 records in one go.
Search and suggest: Try creating a suggestion list, when the user starts typing out something. Fetch results that start with the initial characters entered. However, the API should limit the results to a comfortable number, so that you don't have to parse a lot.
Depending on your use case, you could try one of these.
I have android application that is written "regular" way. layouts, java, APK.
Now, depending on some factors I want data to be presented differently to different users with different preferences, etc. Doing it using XML layouts will be very problematic in couple of reasons:
Upgrade issue - we have bunch of users and they not good at upgrading.
Hard to maintain and code.
So, I'm toying with idea of "templates" where we can serve templates from server and just use device to generate those.
Web app won't work because our data available offline in case there is no connection.
There is buttons and stuff that user can press to call regular Activities and do things.
I envision something like:
HTML 5 template with {tags} that I will populate from data. I will receive tempaltes and data separately from server. I will merge that data and display on UI.
Now my question is how do I:
Display HTML5 inside Activity
Intercept button push in HTML in my Java code?
Is this bad idea to write something like this?
It sounds reasonable to me. You can use a WebView for displaying the content. Your app can manage a cache of downloaded templates and other content and display it in the web view either from the web site or from the cache if offline.
I think your objections to layouts are offbase. You really might be better off with layouts. Here's why:
Your app can be set to auto-update by users if you do not change permissions. But pushing updates to your app will remain an issue unless your app is entirely web-based. (not a bad approach by the way) But so long as you have a native app, you will need to push updates from time to time.
And as far as being hard to maintain and code, layouts are specifically designed to make this type of customization manageable. You can break pieces of the layout common to different settings into separate files, and add them with includes.
You can use fragments to adapt to a variety of form factors.
You can serve up different layout based on screen size, language, orientation, or any of a wide variety of variables.
Check out some of the series on layout tricks, and get more familiar with being a layout power user. I think in the long run it will save you a lot of effort, assuming you don't switch to making your app a web app instead.
http://android-developers.blogspot.com/2009/02/android-layout-tricks-2-reusing-layouts.html
http://developer.android.com/resources/articles/layout-tricks-merge.html
http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
Google: Android Layout Tricks.
Great stuff.
Another benefit: Compiler checking. No broken functionality because a variable or field has the wrong name. Not the case with HTML.
Another benefit: works offline too with no messing around.
And last - you will have a non-trivial amount of work attempting to get this hybrid HTML stuff working the way you want, and then have a very unusual and custom code base that nobody here on Stack Overflow will be able to help you with. Stick with Layouts and there are lots of experts who can help you tackle the stickiest layout puzzles.
There is a specific and official analytics SDK for native Android apps (note that I'm not talking about webpages in apps on a phone). This library basically sends pages and events to Google Analytics and you can view your analytics in exactly the same dashboard as for websites. Since my background is apps rather than websites, and since a lot of the Google Analytics terminology seems particularly inapplicable to a native app, I need some pointers. Please discuss my remarks, provide some clarification where you think I'm off-track, and above all share good experiences!
1. Page Views
Pages mostly can match different Activities (and Dialogs) being displayed. Activities can be visible behind non-full-screen Activities however, though only the top-level Activity can be interacted. This sort-off clashes with a "(page) view". update -> Read http://android-developers.blogspot.com/2010/12/analytics-for-android-apps.html and accept it.
You'd also want at least one page view for each visit and therefore put one page view tracker in the Application class. However this does not constitute a window or sorts. Usually an Activity will open at the same time, so the time spent on that page will have been 0. This will influence your "time spent" statistics. How are these counted anyway?
Moreover, there is a loose coupling between the Activities, by means of Intents. A user can, much like on any website, step in at any Activity, although usually this then concerns resuming the application where he left off. This makes that the hierarchy of Activities usually is very flat. And since there are no url's involved. What meaning would using slashes in page titles have, such as "/Home"? All pages would appear on an equal level in the reports, so no content drilldown.
Non-unique page views seem to be counted as some kind of indicator of successfulness: how often does the visitor revisit the page. When the user rotates the screen however usually an Activity is recreated, thus making it a new page view. This happens a lot. Maybe a well-thought-through placement of the call might solve this, or placing several, I'm not sure.
How to deal with Page Views?
2. Events
I'd say there are two sorts:
A user event
Something that happened, usually as an indirect consequence of the above.
The latter particularly is giving me headaches. First of all, many events aren't written in code any more, but pieced logically together by means of Intents. This means that there is no place to put the analytics call. You'd either have to give up this advantage and start doing it the old-fashioned way in favor of good analytics, or, just be missing some events.
Secondly, as a developer you're not so much interested in when a user clicks a button, but if the action that should have been performed really was performed and what the result was. There seems to be no clear way to get resulting data into Google Analytics (what's up with the integers? I want to put in Strings!).
The same that applies to the flat pages hierarchy, also goes for the event categories. You could do "vertical" categories (topically, that is), but some code is shared "horizontally" and the tracking will be equally shared. Just as with the Intents mechanism, inheritance makes it hard for you to put the tracking in the right places at all times. And I can't really imagine "horizontal" categories. Unless you start making really small categories, such as all the items form the same menu in one category, I have a hard time grasping the concept.
Finally, how do you deal with cancelling? Usually you both have an explicit cancel mechanism by ways of a button, as well as the implicit cancel when the "back"-button is pressed to leave the activity and there were no changes. The latter also applies to "saves", when the back button is pressed and there ARE changes. How are you consequently going to catch all these if not by doing all the "back"-button work yourself?
How to deal with events?
3. Goals
For goal types I have choice of: URL Destination, Time on Site, and Pages/Visit. Most apps don't have a funnel that leads the user to some "registration done" or "order placed" page. Apps have either already been bought (in which case you want to stimulate the user to love your app, so that he might bring on new buyers) or are paid for by in-app ads. So URL Destination is not a very important goal.
Time on Site also seems troublesome. First, I have some doubt on how this would be measured. Second, I don't necessarily want my user to spend a lot of time in my already paid app, just be active and content. Equivalently, why not mention how frequent a user uses your app?
Regarding Pages/Visit I already mentioned how screen orientation changes blow up the page view numbers.
In an app I'd be most interested in events/visit to measure the user's involvement/activity. If he's intensively using the app then he must be loving it right?
Furthermore, I also have some small funnels (that do not lead to conversion though) that I want to see streamlined. In my mind those funnels would end in events rather than page views but that seems not to be possible.
I could also measure clickthroughs on in-app ads, but then I'd need to track those as Page Views rather than Events, in view of "URL Destination".
What are smart goals for apps and how can you fit them on top of Analytics?
4. Optimisation
Is there a smart way to manually do what "Website Optimiser" does for websites? Most importantly, how would I track different landing page designs? update -> Seems I could use the Custom Variables for that. More details are still welcome.
5. Traffic Sources
Referrals deal with installation time referrals, if you're smart enough to get them included. But perhaps I'd also want to get some data which third-party app sends users to my app to perform some actions (this app interoperability is possible via Intents).
Many of the terminologies related to "Traffic Sources" seem totally meaningless and there is no possibility of connecting in AdSense.
What are smart uses of this data?
6. Visitors
Of the "Browser capabilities", "Network Properties" and "Mobile" tabs, many things are pointless as they have no influence on / relation with my mostly offline app that won't use flash anyway. Only if you drill down far enough, can you get to OS versions, which do matter a lot. I even forgot where you could check what exact Android devices visited.
What are smart uses of this data? How can you make the relevant info more prominent?
7. Other
No in-page analytics. I have to register my app as a web-url (What!?)?
Google Analytics is pretty good for basic tracking of Android app usage. If you need more mobile-app-focused analytics you may also want to look at these:
http://www.flurry.com
http://www.capptain.com
A benefit of these over Google Analytics is that they are designed to track mobile app usage, rather than web site usage, so are more specific in what they do, but to be honest there's always going to be work for you to do to define what actions within your app matter to you enough to track - that's more about the needs of the business, than the technology.
I am not convinced with google analytics for tracking our application. Because as per my requirement i would like to get the error or crash report from my launching application in market. From this error report i could see the stack trace of the crash so that i can fix my bug. But from google analytics i am not sure how to get these details, I would suggest the best crash report trackr is Acra you will get more info here http://code.google.com/p/acra/
If someone know how to get these crash report using Google analytics please share.
I've no analytics experience but after searching a while i found this page Flurry-vs-Mixpanel-vs-Google-Mobile-Analytics-who-wins-Why and i think you can find useful information and I also decided to use Flurry
it's been some time now, since I started reading about android.
I've already made a few basic applications, but I still miss something: How is actually sharing application component being done?
This is what the Android Dev Guide says:
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
I think I came across some question like this, but I think I'm still confused.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Is information about the data that the application operates with private, too?
If it is described in the AndroidManifest.xml file is it available for the other applications, or it is available only to Android?
When I started satisfying my interest in Android - one of the things that grabbed me was the impression of immense interoperability...
:)
Have I been wrong or I still haven't found the way?
Thanks!
How is actually sharing application component being done?
That depends entirely on what you consider an "application component" to be, and what you consider "sharing" to be.
This is what the Android Dev Guide says
That is a fairly bad piece of the documentation. Here is how I would write it:
A central feature of Android is that one application can make use of components (e.g., activities, services) of other applications (provided those applications permit it). For example, if your application needs to display a list of contacts and another application has developed an activity that does just that and made it available to others, you can call upon that activity to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application. Rather, it simply starts up that piece of the other application when the need arises.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Either developers are intending for you to integrate with them, or they are not. If they are, they should be documenting how to do that (e.g., Intent formats to be used with startActivity() to trigger their code). If they do not document such integration points, you can certainly ask the developers to add some. However, randomly shooting Intents at them in hopes of getting a response, even if it temporarily works, is little better than script kiddie tactics -- those developers are not obligated to ensure you code works when they upgrade their app.
Is information about the data that the application operates with private, too?
I do not know what "information about the data that the application operates with" means. Data managed by an application is private by default. Again, application developers can offer integration points for data (e.g., content provider, remote service API) -- some do, some do not.
one of the things that grabbed me was the impression of immense interoperability
Android offers greater interoperability potential than some other mobile platforms. However, using that potential requires consent among the interoper-ees. You cannot unilaterally decide to hack into another app's database, or invoke private activities, just because you feel like it.
Should more Android developers offer more integration points? In the abstract, sure. However, bear in mind that this adds support costs (e.g., answering integration questions) and limits coding flexibility (e.g., need to maintain a stable API for those doing the integrating). Developers cannot be blamed if they do not wish to incur all that.