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.
Related
I always wonder how apps like Airbnb, Flipkart, and Swiggy update their UI on the fly. Even if I didn’t update the app, Flipkart shows different UIs during festivals, while Swiggy always changes its UI based on the device location.
How I implement this in my react-native-app?
Webview is the solution?
Kindly help me..
Thanks
There are multiple ways you can go about doing this.
One way would be to use WebViews as you've mentioned, this would make it trivial to change the interfaces as it's entierly controled in the servers. But the main issue with this approch will be performance and non native look and feel. These are the two main advantages of using React Native over hybrid frameworks in the first place and therefor, it wouldn't make much sense to use WebViews everywhere. But if there's a small slice of your application that updates regularly(ex - terms of service) you could use a WebView to do the custom views.
A more common way that's low effort would be to have all the code in place for the different looks, but use feature flags to toggle different views. This would work the same way that a dark theme would work. The amount of customization we can do this way is limited because we need to code everything ahead of time.
Another way is to use server driven UIs. With this approch, you will have a pre defined templates in the client that you them populate on run-time with data from the server. For a very simple example, you could have a header image that could be populated with a seasonal greeting image. But instead of simple things like images, this can be much more visible chagnes as well. (ex - List view instead of Grid View)
One more involved way would be to use code push. This would allow things like seasonal UI changes. But this requires a lot more setup and might not provide the best user experience.
Webview is best because this way you can change the UI and the business logic or UI handling logic.
But you have to develop a minimum architecture for that.
Here is my way.
Develop Host layer to use camera, shared preference, file system etc.
Develop a communication layer which will be responsible for communication between your webview and the host layer so that your webview can access all the required device platform(eg. android or ios) features which can not be normally accessed directly from webview.
So now you can render whatever UI(by HTML and CSS) you want, you can put whatever logic you want via javascript also now you can access all the required device features you really need.
So, now you are the king of your app.
Just you have to keep updating the UI or logic in server when you really need.
Some cons are there like
webview in android is different than our normal browser. Some required features are not available.
Its behaviors is different in different API level. So you have to test it very well. For testing, you can use Genymotion.
It does not work well in some old devices/APIs.
Look and feel really matters. But smart design can fix that problem.
If you want your whole app in a single webview then you have to compromise with page transition feature of android or ios. But again smart animation design will fix that.
But this is just a working solution not a smart solution for server driven UI.
I have used some server driven UI frameworks. But they seems to be overhead and lacks some features.
So there should be a framework by which we can render native UI dynamically from server with corresponding business logic change feature and accessibility of all the possible device functionalities.
A few months before I started to develop a Server driven UI framework. I did it little bit. But due to lack of time I really could not complete it.
If someone interested to contribute in this project feel free to contact with me.
I have a solid idea and architecture for this project.
This framework can create a revolution in the world of app development.
email: bedmad82#gmail.com
I am a new guy to full stack web application development. I want to design a web application which has data stored in say back end databases. Now I want to design a desktop web client as well as android application which will be able to fetch data from back end. So how do I need to start? What APIs can be used or how can I expose data from same back end to multiple clients?
Also I want to handle massive amount of request. How to design such a system? What to use in back end to store data and handle requests efficiently.
Any video / document / reference containing useful information will be much appreciated.
Wow, you have a whole forest of questions to settle. You are going to need to go do your own research on such things as algorithms and data flow for your application before you can make any reasonable choice of platform. Here are a couple of basic ideas to get you going: 1) look at Java and Node.js. There are lots of other possible platforms but chances are you will end up using one of those two. Try to think about what the actual code you will generate in each of those will look like. A little or a lot? 2) Just store your data in files, most probably using JSON. Maybe you will end up doing something more fancy after you figure out where you are going with your project, but you will be surprised how well the simple file-based solution will scale.
When you have done a bunch more research, and maybe even coded up a few ideas on your platform of choice, then come back and massively edit your question. Only then will specific suggestions for tool choices be possible.
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?
I'm creating an app that needs to display a table, with say, 30 columns and 30 rows. I want the user to be able to use swiping to move around the table/spreadsheet. The idea is that probably the entire table will not be visible on the screen, and if it is, it will hardly be readable, so there will have to be some max-columns-on-screen value. Each cell in the table must be capable of being a different color than the rest.
So far, I've looked into TableLayout. This doesn't seem to support different colors or swiping... actually, it does support different colors via .xml, but this isn't changeable at run time, and seems like it would be very messy anyway.
WebView looks to be an option, as I am proficient with HTML/CSS but can't find many resources about creating HTML and CSS content on the fly with android - only loading it; although I can imagine writing a file with the data and then loading it, and deleting the file. Not sure if any of this is good performance wise.
What direction should I head, before I start heading in the wrong direction? :-)
Yes, it is possible (and not difficult) to support different colors and gesture in the tablelayout rows.
I think it is always a wiser choice implementing the native components, once it has a better performance and it has a better layout adjust to different android versions.
Either method can solve the problem, so it's a judgment call based on your goals and requirements.
On the plus side for Android native views:
They are pre-compiled and easier to parse than HTML, so they will load faster, scroll more quickly, and require less memory.
If you intend to write a lot of Android apps you will need to learn them.
If you took this route, a typical approach to draw multiple columns would be a ViewPager with sliding tabs. See for example the Google Play Store app.
It's not the case that coloring native views dynamically is impossible or messy; it's not hard at all but it takes time to learn how, which brings me to the plus side for HTML/webview:
A programmer with expertise in HTML will solve problems faster by just using HTML.
Layouts designed in HTML for an Android web view can be re-used on other platforms.
Again, it's not really hard to load dynamic HTML into a web view. There are a few tricks you will need to learn but that's it.
As a beginner wanting to become more familiar with the android platform, I wanted to create a web client for a website.
Something similar to https://play.google.com/store/apps/details?id=com.krinsen.javadocreader&hl=en
However, I am confused about how the author created the custom UI for the java docs.
To my understanding, there are 2 ways to do this.
One approach is with WebViews. I quickly prototyped a sample of this but I believe (correct me if I'm wrong) that I can't change the UI of the WebView and will have to view the page from the perspective of a browser. Unfortunately, this does not look very well as the website was not mobile optimized and there are inconsistent spacings and odd whitespace.
The second approach is to manually create each View using the different layouts provided by android (LinearLayout, TableLayout, etc). This should create a more custom mobile experience as I can manually construct how each page will look. However, this seems time-consuming as I will need to manually create a different UI page for each page of the website. Also I am confused as to how to pull the data from the website as each new view in the new UI will need the content from the website. Do I need to do HTML parsing to pull the content or is there a better way in the android sdk? What is a good approach that android developers take to extract the different forms of content from a website to redisplay on a android client?
Finally, since I have a very beginner understanding of this situation, am I correct in assuming that most likely the creator of the application mentioned above did something similar to the second approach I mentioned?
What is a good approach that android developers take to extract the different forms of content from a website to redisplay on a android client?
I think the best way is to provide an API for native application. Parsing HTML might look nice untill you need to suppport every change in your HTML page. But if you are not the owner of web-site there is no other choise if only you don't contact owners and ask for an API.