We need to create an app, which works for time tracking of the employees as well as location tracking.
We only want to program it for Android, but we don't have any Android skills.
Therefore phonegap came as a great alternative.
But there are several questions, to which I can't find a clear answer in the web.
If the phone is in standby mode, can the phonegap-app still send position data? Would this still be phonegap standard or do I need to use plugins?
the smartphones will be very simple and cheap. Is there a higher risk, that the phonegap application gets closed by Android to free memory then for a native app?
Alltogether, could it be recommend to invest the time to learn Android or would it be better to stay at our language JS?
It’s perfectly feasible to write a location tracking application using phonegap and have it a) work in a performant manner on low spec android phones and b) keep the app running in the background when the phone is in standby mode.
To keep the app running in the background on android, it’s necessary to acquire a partial wakelock (see android powermanager). In phonegap, you need to use a plugin to achieve this. On the plus side, there’s an existing phonegap plugin to do this. The downside is that in order to use a custom plugin, you will not be able to use the convenient phonegap build method to build your app, so will need to do the manual process via the Eclipse IDE, but this is not a great hassle to set up (see here).
In terms of your app getting closed because of android running out of memory, and also having it perform responsively on cheap, low spec devices, this won’t be a problem so long as you are careful to write your javascript code in an optimal way. I’ve implemented a location tracking app using phonegap which uses custom maps and in testing on older android devices including HTC Desire and HTC Wildfire, performance was acceptable and the partial wakelock worked - I had no problems with the app getting closed because of lack of memory.
I chose phonegap over native because I’m a web developer so Javascript is more convenient for me than having to start from scratch with Java and the android SDK, and also because I was able to use the same JS code base with appropriate plugins to produce the same app for iOS. Phonegap is able to access GPS hardware on the device and in testing outside I found the average accuracy to be between 4 to 8 metres depending on the device.
Hope this helps!
Related
I have a medium size project on React+Nodejs and I need to choose best suitable technology for the mobile part. I am considering React Native or Web Progressive Apps for that. I want to ask you guys what is your experience so far about performance of "native-like" React Native versus WPA based apps.
I need to put into consideration:
1. Making it as easy as possible to make a transfer from ReactJS code into mobile.
2. Hardware support on mobile devices. Such as Barcode reading and NFC.
3. Push notifications.
4. Function well on both Android and iOS.
Biggest question is whether WPA technology has already become mature enough to trust it or not.
I had to make the same decision couple of months back and we chose PWA (not the answer for everyone yet).
Here is why we chose PWA,
1) Performance - Web can now perform 60fps - The magic number needs for native like smooth transitions.
2) Cost - Its fast and easy to build a product for both as a mobile app and web using PWA with no learning curve for existing web developers.
3) Proven - Starting from Twitter lite to Flipkart, there are so many success stories on PWA. No doubt its reliable. With iOS support coming couple of months back, now all major browsers support it.
PWA limitations and workarrounds,
1) Hardware - PWAs are limited to what web can do today. So there are hardwares like bar-code scanner we don't have any scope of support anytime soon and there are some hardware which very limited support and some hardware like Bluetooth with average support(in terms of % of browser versions supporting today) We had to build a small Android Native application to interact with these hardware and pass on the info to PWA suing web sockets. Say, when a barcode is scanned, this native Android service will listen for and receive it and pass on to our PWA. Same thing goes to NFC.
2) Packing and deploying - There is no official way to generate an APK and distribute in corporate environment. We were able to extract the APK after adding the PWA app to home screen using some file explorer and use that to distribute though. Havent tried on iOS. Hope for latest versions for any mobile OS, we can use cordova(not pure PWA but we get most of the benefits like Service Worker) to package and distribute as well.
I’m completely new to Qt mobile, I even don’t have a solid mobile dev experience, so sorry if I’m asking something obvious.
I need to develop a mobile app that should have the ability to receive a call like functionality (over internet, not GSM call). When answered, it should start streaming audio and video from our server. The call should be one way only, meaning, that stream goes from server to device, but never from device to server.
So my questions is:
Is this possible in Qt? I chose Qt because I’ familiar with it and I want to support desktop, android and ios. maybe windows phone later.
Is it possible to receive a call when the screen is shut off and my app is not running? I mean, this is a mobile device, the app won't be running all the time, it should be started only when a call is made from server to device. How can I achieve that? I think Viber, Skype and other messaging apps do that.
Many thanks in advance :)
1 - Well, sure it can, although it might not be as easy and straightforward as you'd want. Qt Multimedia does provide the necessary classes, but you do have to check how supported they are on the platforms you need to target.
However, the classes Qt provides are either too high level to serve any purpose but their intended purpose, or too low level, so you must implement pretty much everything by hand. In this aspect, the benefit of Qt being capable of producing portable apps may not outweigh the ease of using certain platform specific libraries that offer video streaming out of the box. In other words, it might be easier to write separate Android and iOS apps using Android and iOS libraries than a single Qt app that will work on both.
But just in case you decide to go with Qt, as I mentioned for the time being you are left with one option - do most of the work yourself. This means you should record audio using QAudioRecorder and capture frames periodically from a QCamera in a buffer of given length, compress that data (and preferably encrypt it if security is a concern), send it to the client over a QTcpSocket connection, decompress (and decrypt) the data and play it back in sync. It is certainly doable, but as already mentioned, it will be much harder since Android and iOS libraries offer pretty much "out of the box" solutions. Alternatively, you might decide to use a third party solution that offers support for all the platforms you target.
2 - whether your screen is on or off - that will be a call to a platform specific API, so are requests to turn it on or to keep in on for a given duration. Whether your app is running on the device or not, that is easy - just try a TCP connection with the client on the device, if it succeeds then the client is running. If you want to receive calls while your app is not running, you will have to implement a platform specific service that runs all the time instead and starts your application when a call is received.
QT Mobility does not have a a framework for supporting VoIP as you can see from the reference :
http://doc-snapshot.qt-project.org/qt-mobility/
You could create the VoIP framework of your app natively (which is going to require a good understanding of the various audio and video frameworks available) but another way to go
would be to use a VoIP SDK that supports both iOS and Android such as the Twilio mobile client
https://www.twilio.com/client/mobile
Qt mobile will help you in your application's UI, however you will have to write some native code for each platform you are going to use. Note that Qt is extending fast, you might need not to get your hands dirty with platform specific native code in upcoming versions of Qt.
Yes, you can receive a VoIP call when your application is closed by creating a background service (but as I know so far Qt doesn't do the job for you, you'll need to do it natively), it is the way Skype and Viber work.
As per I know new Blackberry10 OS using qt for developing. There is one source code available about VoiP Calling in qt. I am still searching about video call.
Check below link, May be helpful
1) Blackberry Developer Blog
(2) PjSip Blog
(3)Download Source Code
I don't know how to develop app in Android, ios, desktop using qt language.
But I am suggesting develop app in all native language instead qt.
Hi everyone am new to android and developed projects on c, dot net frameworks and python. I have to develop application for android and iPhone tablets. Currently I have to write application for android and have two options.
1) Use java and android sdk
2) Use Phonegap
I would love to use Phone-gap because it's seems pretty much easy as I am familiar with HTML, CSS and JavaScript. But that's not my limitation as I have used jav with E-clips earlier. much better hint is single app for android and Iphone.
My question is if phone-gap will work for me. what I need to start my app on start-up without showing desktop and always on top. and read screen on/off actions. I have crafted kiosk and installed 10.1" android 4.1 tablet. I have to develop app to give it a POS look. My app should start as early as my device boot and always remain on TOP unless explicitly closed.
Any suggestion will be helpful for me as I am new and have only created hello world app on both.
I've been developing a mobile app for both iOS and Android. Due to time/budget constraints, we initially selected PhoneGap/Cordova as mobile app framework so we could write once and deploy to both platforms.
This plan has worked fine for iOS, but we're finding that Android's browser/engine is kind-of a piece of garbage (to put it nicely). Every time we add a new feature, we find one more thing that the Android browser doesn't support, or only partially supports, or fully supports but will randomly fail from time to time, etc. Even once we code around the Android issues and get things working smoothly, test it on multiple devices/versions, and deploy a new app to the Android market, we immediately start getting emails and reports from customers who can't get the app to work on their device. We have them uninstall/reinstall, reboot their phone to clear the memory, etc., and their device still consistently fails (and by "fail", I mean it typically just freezes and/or won't respond to touch input - it usually doesn't crash, or anything). The app works fine for most people, but there are still quite a few devices that inexplicably fail.
I don't mean for this to be a rant, I'm trying to analyze whether the Android+PhoneGap path is the correct path for us. Specifically, I'd like to find out the following:
Are there people out there having success with an Android+PhoneGap app? or is Android+PhoneGap always going to be a problem on certain devices?
Am I likely to have more luck with a native Android app (I've never attempted one)? Or are multiple devices/versions always a problem on Android, even with a Native app?
1) Yes. There are are good apps which are based on Phonegap and works well in all devices.
2) It depends on what features of the Android you are going to use. Few versions that does not support some features that's available only to new version.
BTW, what is the minimum required version that you have selected for your app? I assume you are developing the app with Android as base version.
When creating a new Android project, you have to set the minimum required platform version. If you set something higher and use the app in a lower version which does not support the feature, results are going to be different.
After having worked with Android+Cordova for some time now, I have the following suggestions/comments for anyone thinking of going that direction.
Consider using Sencha Touch, or jQuery Mobile, or another mobile framework that has already coded around the Android-browser issues (which there are a LOT of). Consider not straying too far from the default styling that come with those frameworks. Simply styling a normal web page to look like a mobile app is a constant headache to get working on multiple versions of the stock Android browser.
Although the stock Android browser is garbage, Mobile Chrome is pretty nice. In Android 4.4, the Chrome engine becomes the default engine used by a webview of an Android app. If you don't like Sencha or jQuery Mobile or the like, you could hold off and just use a mobile web site for a while until Android 4.3 and below become insignificant. It's not hard to get things working on Mobile Chrome.
Even without Sencha/JQM, you can still muscle your way around the stock browser issues, but it's almost as frustrating as developing for IE6. Okay, maybe not that bad… but close.
I've started experimenting some with a native Android app, and, so far, it seems like less of a headache than building an app with Android+Cordova+lackOfSenchaOrJQMorTheLike. The things I've experimented with work pretty consistently among different Android versions. But I don't have much experience there, so I can't comment too much on a native Android app.
I tried Kony Studio recently at a client. How does Kony Studio compare to other IDEs/frameworks for native iphone/iPad/Android compared to HTML5 development? I am working on a cloud-based adaptive learning solution that allows students to browse knowledge, test themselves and receive automated feedback about their performance.
Never even heard of "Kony Studio". Website info is light and/or badly organized. Looks like the kind of thing they sell to "business people" who then force it on their devs. Most cross platform mobile dev is bad at this point. Best bets are either Phonegap, for HTML5, or Appcelerator Titanium. I would recommend neither, although I'd lean towards Phonegap. It really depends on how simple your app is, though. Complex forms/interactions don't work well with HTML5, yet anyway. Seems to work better on iPhone, but I think that's due to more effort being put into the JS frameworks for iPhone, as well as Android fragmentation seems more visible with HTML5/JS apps for some unknown reason.
I think HTML5 based apps will eventually become more prominent, then "the standard", but today its rough.
I'd use PhoneGap with something like jQ mobile. The market definitely moves towards good /simple standards like HTML5 and CSS. The hardware acceleration is coming into browser rendering arena and "slow HTML" is going to be over with in 2-3 years.
Stay away from KONY at all possible cost. The IDE is just a set of plugins into eclipse but here is where it all starts.
The installer that you get from them does not work everywhere (i.e. hangs on some machines). Once IDE installed, the WYSIWIG feature (UI designer) is a joke. The demos look OK but in reality it is a tedious tasks to layout widgets correctly. You end up writing versions for every screen size and channel (Android vs iOS). On Android the scaling is not handled at all, for example, run your app on Galaxy Note and see that all form layout is completely skewed. KONY 4.x does not support device pixels and relative margins and paddings at all (you specify them in PIXELS!!!).
The biggest selling point is "drag-n-drop, don't write code". In reality KONY IDE generates LUA code (4.x) that DOES NOT handle any edge cases, such as no cell network. When you build a simple app that transacts a web service and your cell signal goes down your app just hangs then crashes with internal Android error and then re-running the app does not help until you terminate the corrupted process. To do a usable app one needs to write all code by hand in LUA. There is no easy upgrade to KONY 5 - the "auto convert" tools is a marketing feature.
So one thing to keep in mind is that Kony v4 was a complete overhaul, switching the core engine away from Lua and making Javascript the scripting language. Kony has a very fast release schedule, and is now on version 5.5, which is a vast improvement. There has also been the addition of a new UI design tool for Kony called Visualizer, which makes the process of creating the UI an experience that is like using a wire framing tool, but the output from Visualizer is the UI is translated directly into forms in the Kony Development platform, which makes the task of creating UI's much easier.
The real advantage of Kony is that they have a Service Level Agreement ( SLA ) that guarantees that your applications will work with new OS and platform releases within 30 days of being released to the developer community, meaning that your code is "future-proofed". This becomes a significant accelerator to your overall development approach, as you are not saddled with having to keep updating your code for each new OS update.
Kony also has embraced a complete SDLC approach, with three distinct cloud products that are designed to work independently or together, covering UI ( Visualizer ), development ( Kony Studio ), and Management of apps and devices ( MAM and MDM ).
You can trial all the products now for free at: http://www.kony.com/trials