Currently i am developing an Android Hybrid application. I am pretty new to Android development but picking up new things pretty much every day. This Hybrid application is build upon the Sencha Touch 2.3.1 framework. The project consists out of the following of main goals.
Functionality:
Getting the current GPS location. (Backed by 2G/3G or WiFi if needed)
Reading the current accelerometer values. (Used for a fall-detection algorithm)
Scanning QR codes. (I will probably use a library for this function)
Setting a timer and let it run in the background.
All of the above should 'run' in the Native part of the application.
General question: What would be the best way of doing this, in terms of architecture/base structure?
To get a little more specific on the answer i would like to get, here is some more information.
Currently the native part (Activity) of the application looks somewhat like this. It declares and initializes the WebView and loads the URL which refers to the host where my Sencha Touch application is hosted. So far this is the only Activity/Class i have. And also works properly.
I am using the following bridge to communicate back and forth between the hybrid and native part of the application. In the example on GitHub they stuffed all of the functionality in one Java class. (Activity)
In my case this would mean for my project, that all of the Hybrid to Native function calls, like getting the current GPS status, set a timer in the background or start the camera will reside in the main Activity. Thus getting quite big in time, i could imagine.
Sub question: Is this the way to go, or should i split up all of the core functionality in separate classes?
Scenario:
The GPS sensor takes quite some time to get a fix, so the user should not be interrupted while the GPS keeps searching for the current coordinates. (Again this can be backed by 2G/3G or WiFi if needed and available)
Sub question: Should this or any other background functionality be handled in a separate thread? Or in the same Activity where the WebView resides? Or can i just simply create a new thread within the Activity that handles the GPS and/or other functionality that require to run on the background?
As you can see i am trying to figure out the best way of structuring the application on the Native side.
For the threading part (Functionality that runs in the background, such as a timer or GPS that waits for the correct coordinates) i wanted to use IntentService, because the functionality has to keep running and also finishing their tasks, even when the application is not active/minimized. Plus the same task is bound to be handled again. (Re-using the thread?) So when i speak of threading or threads in this question, i mean using the IntentServices.
I hope i was clear enough. Thanks for reading so far.
(Pseudo)Coding answers are appreciated, but showing me the best/correct structure (Image or 'just in words' -like) would be preferred. Then again, do as you prefer.
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'm knee deep in this commercial game and currently working on the in-game chat. How I code the chat system depends on rather or not threading will work.
My question(s)....
Does anyone know for sure calling a thread on android or ios will result in a separate process and not hold up the app until complete?
This worries me because I came across another python user who was developing some form of app and they stated that their thread did not run as an individual and their app froze up until the thread completed. (which sucks because python is a cross-platform language)
What I wanna do is have a thread periodically fetch chat data from the server without causing the whole app to pause while doing so. This will allow for a more professional looking chat system and better user experience.
However, if for some reason python threads will not act as expected, I'll have to use a different logic for the chat system.
I'm sure some of you will probably be like, "just test it" but that's just it....I don't wanna (want to, lol) write all that code just to re-write it all over again if for some reason threading doesn't act right on a phone.
I'm not asking for code here....God knows I can code the hell out of an alien battle cruiser from planet Zars equipped with warp 7.5 engines.
If no one can give me a for sure answer then.... (sigh)...... I'll have to just write the code and cross my fingers in hopes of accurate threading behavior on phones for python programmers or be faced with the devastating task of re-writing a large chunk of code..... on the client and server side!
=====================Update as of July 14 2017==============================
I went ahead and wrote the code anyway. Turns out the Kivy API set has some back-end issue with creating Rectangle draw instructions in a python thread. This issue doesn't seem to be relevant when creating widgets from within a thread.
I did find a work around for the draw instruction issues and had things the way I pictured it all but in the end... I saw more cons than pros in the way I was planning my chat system and decided to re-write it anyway.
The new chat system is easier to work with and I don't have to implement code and fonts for multiple languages. (phew!)
So....looking at my original question now....
Yes,
Python threads will run on their own cpu cycle on an Android phone but what you're trying to accomplish depends on your entire setup...back-end and front end APIs.
I'm surprised to see people assume python can't thread when the language has the modules for threading.
Hell I run threaded processes separate from the main thread all the time on PC. In fact, I have this nice email app which can generate emails and send out ads/flyers and maintain a valid email database.
The app uses threading to update the UI system so the user of the app knows what's going on in the background. It's a marketing tool I plan on using later after I release the current app I'm designing now.
I might even release my marketing tool but such a high quality app wouldn't be cheap on the market. Not when marketing cost so much money. Being able to reach your target audience at little to no cost... Sounds too good to be true.
:)
I am currently working on a Phonegap Cordova 2.5 app that requires the user to take a picture and upload it to our servers. I am using PhoneGap in order to avoid any Android specific coding (and possibly publish it on iOS some day).
As it turns out, Android frequently (but not always) kills my app while taking a picture and by the time the camera module returns a picture, my base app gets restored from scratch and no callback method gets invoked. Any reference to the newly taken picture is lost, see this post here:
Taking a picture from the camera fails 20% of the time
A common workaround seems to be native Android code. Which leads me to my question: Why should I use Phongap if the first and only Phonegap module I am using (the camera) needs some serious hacking? I am aware this is not even Phonegap's "fault" but rather Android life cycle design, but still: How can I defend this choice of architecture? Has it all been reduced to a reusable front end using HTML, CSS and JS? Should I switch to native Android?
Answering my own question: PhoneGap is awesome in many ways, so there are numerous arguments to defend it. Most notably, the whole UI needs to be coded only once and being Javascript and CSS there are many developers who don't need to learn another language. Don't underestimate the value of "easiness", if you need to code a relatively simple app, don't bother to go native. PhoneGap will just do fine.
In my case, the app I wanted to build revolves around taking photos. So I don't use the camera in some rare use cases to spice up the user experience, but it is rather the most important part of the app. In this scenario I guess the recommended approach is to go native. That's what I did in the end.
Another approach would have been using a PhoneGap Plugin called "Foreground Camera".
PROs: Seamless photo taking in the integration. The user actually takes the picture INSIDE your app.
CONs: By default you lose ALL of the camera's capabilities (zoom, front camera, flash, etc.), so you would need to make a serious coding effort to implement some of those features manually.
This Android app developing business is accelerating the brown-to-grey-color conversion of my hair.
Can someone tell me how I'm supposed to get aFunction() to run when the app starts, seeing as I'm not supposed to make a while(true) inside onCreate()?
I've read the tutorial on Android Developer, several other tutorials, multiple questions on here, but none have answered this, seemingly, simple question. Or, at least I haven't been able to find it - without a doubt because I'm asking the wrong question to the great oracle of Amphitheatre Parkway.
The app is my first homemade non-tutorial app, and I'm attempting to make a speedometer based on GPS (obviously). Basic stuff I guess. It needs to update ever so often which I'm using Thread.sleep() for. Setting up LocationManager, getting location, calculating distance and speed is working. Printing the speed is working. Everything, except making it run, is working (he claims in his naivety).
Android development (and in fact most GUI development) is very different than the console development you may have done in the past. The main difference is that GUIs are event-driven. You typically create what are called "callback methods" which respond to events. This allows the system to do other things rather than waiting for a while(true) loop in your app. I am unfamiliar with using GPS in an Android app. You will need to research what callbacks are necessary to deal with GPS notifications. I suggest starting with Making Your App Location Aware and Location and Maps.
I just got done writing an Android Activity that allows other Activities to call it for some result (it's not intended to be a stand-alone Activity). I'm now working on the equivalent iOS application and can't find any resources for how I would enable similar functionality on iOS.
The situation: The tool I'm producing is intended to be used by other applications, rather than as a standalone application. The thing is, the GUI that needs to be presented to the user is rather involved so I'd like to be able to provide the developer with a "all-in-one" package that they can simply launch and get results from. Doing this in Android was very straight forward. I simply wrote an Activity and instructed the developer to launch this Activity for result. I've looked around and can't find a similar functionality to allow an iOS developer to do the same. What would be the best way to go about doing this?
I think part of the problem I'm having in finding resources is that I'm not entirely sure what what I'm making is called. A library? extension? plug-in? I would think a library doesn't have a GUI and it seems extensions and plug-ins are made for an extensible application (that is, one in which the user can install the extension/plug-in).
Your API could be à single call that would pop up a modal view. A target and selector can be specified to receive an answer. Supplying it to other developers means packing it into a "framework". I'm not sure if you can include resources.
There isn't really any equivalent. The closest you can come is having the second application call UIApplication's openURL with a custom scheme that is listened to by your app, and then when your app is done it would do the same with a custom scheme that is listened to by the calling app.
In practice, the iOS app would usually include the entire activity-equivalent as some sort of library, which at the high level would take the form of a UIViewController subclass that is presented modally and then calls a delegate method or completion selector of some sort on completion.
iPhone development is a different design than Android development, so you may need to rethink what it is you are trying to do.
Most likely you will want to look at just including the code in each program, initially, just so you can get it testable, but that may not be the best solution.
But, without knowing more details about what you are trying to do it is hard to give some suggestions as to better solutions.
For example, you may find LocalNotifications as one solution (http://useyourloaf.com/blog/2010/7/31/adding-local-notifications-with-ios-4.html), but again, it depends on what your needs are.
I found that using local notifications to call a REST service, then to process it and decide if I need to inform the user was helpful, as a replacement for how I used Intents in the Android application.