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.
Related
I have a very big problem and unfortunately I cannot find a solution. Help from some professionals would be really great. Thanks!
The little problem
I have a Angular Web App / Android App using Cordova. My app needs at least the Chrome Engine 50 to support all functions and looks right. Unfortunately I noticed that there are many devices that use a much older version. Also the devices do not use a common source for the Chrome Engine. Some use the Chrome Browser itself or the Android System WebView. In these two cases I can tell my testers, install the two things and then it works. Currently I check at the start of the app which version is installed and if it is less than 50 I show an info that users have to update ther apps / components particularly important here the two things (Chrome Browser itself or the Android System WebView). I rather say my users that they should update all ther apps because some hardware manufacturers have their own apps that include the Chrome Engine. That alone I find very unpleasant.
The biger problem
But it is worse with devices that have their own Chrome Engine built into the firmware. So one that you can not update at all via the apps update only just the hardware manufacturer of the phone can update them with firmware updates. So many cheap devices that don't get any more updates simply fall out and bring me possibly bad ratings.
What can you do?
Maybe someone has an idea? Because this way I can put my app in the store from Android 4.4 on but even 6.0 devices have older Chrome Engine versions in their firmwares. Can't I provide a chrome engine version or say I use it there from Chrome or from the Android system WebView? I'm really on the edge and need a clever solution.
I would be very happy about some help or exchange. Thanks a lot.
Best regards
Robi
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In 2015 Google introduced a new approach for developing web apps for Android: progressive web apps. One can create an application that will look like a native application, will be able to use device's hardware like camera and accelerometers, receive push notifications, have a launcher icon, work in offline, store local data, etc.
On Android, what features do native apps provide that progressive web apps do not support, and vice versa.
TL;DR - As of Feb 2017, Progressive Web Apps are a sufficiently powerful platform that Twitter has moved all of their mobile web traffic to a React PWA.
As of August 2016, Progressive Web Apps actually offer more hardware access than commonly thought. Here's a screenshot of whatwebcando.today from my Chrome 52 stable on Android:
Hardware access includes
geolocation - supported in the vast majority of browsers
camera and microphone via the getUserMedia/Stream and the upcoming MediaStream Image Capture APIs
device vibration
screen orientation and accelerometer access, including compass and gyroscope
battery status
Upcoming hardware access
These features are being implemented or already work in some browsers:
Bluetooth via Web Bluetooth API
NFC
ambient light sensor (works in Firefox 48+)
proximity sensor (works in Firefox 48+)
accelerometer, magnetometer and gyroscope sensor access
shape detection API
Another important point to note is that the Origin Trials Framework (implemented in Chrome) enables manufacturers to expose and test hardware (or software) capabilities without having to go through the standardization process. For example, a phone maker could expose an API for reading the values of a pressure sensor, refine it, then submit it for consideration to the W3C.
Besides hardware access, there are also software features traditionally employed by native apps that are now available to web apps.
Traditionally native features that PWAs can also use
push notifications
working offline
adding an icon to the home screen
appearing in the apps list thanks to WebAPKs - Progressive Web Apps can now be packaged into actual installable Android packages!
launching in full-screen
clipboard access
hardware-accelerated 2D/3D graphics via HTML5 Canvas or WebGL - check some of the HTML5 Canvas demos, WebGL sites or the three.js library. A 2014 benchmark of the Unity cross-platform game engine compared native vs. WebGL rendering performance, and concluded that
"The most important takeaway is, while there are still areas where WebGL is significantly slower than native code, overall you can get expect very decent performance already, and this can only get better in the future."
The gap has indeed been closing.
reading user-selected files in any browser
slick, smooth UIs with 60fps animations
These features cover a lot of use cases, and many popular native apps nowadays could be rewritten as PWAs. Take Slack, for example. Its open source alternative, Rocket.Chat, is building a PWA version. For more PWA demos, see https://pwa.rocks.
Native-like features coming to PWAs
handling intents — for example, sharing a page to another app, or being the share target, e.g. a PWA chat app that receives an image to set as the user’s avatar
Native Android features not yet available to PWAs
access to the fingerprint sensor (under development)
contacts, calendar and browser bookmarks access (lack of access to these could be viewed as a feature by privacy-conscious users)
alarms
telephony features - intercept SMSes or calls, send SMS/MMS, get the user's phone number, read voice mail, make phone calls without the Dialer dialog
low-level access to some hardware features and sensors: flashlight, atmospheric pressure sensor
system access: task management, modifying system settings, logs
Progressive Web Apps offer features that native apps lack
discoverability - content in progressive web apps can easily be found by search engines but a content-centric native app like StackOverflow won't show among app store search results for content that it does offer access to, such as "pwa vs. native". This is a problem for communities like Reddit, which can't expose their numerous sub-communities to the app store as individual "apps".
linkability - any page/screen can have a direct link, which can be shared easily
bookmarkability - save that link to access an app's view directly
always fresh - no need to go through the app stores to push updates
universal access - not subject by app stores sometimes arbitrary policies or (unintended) geographic restrictions
large data savings, extremely important in emerging markets with expensive and/or slow Internet access. For example, e-commerce website Konga cut data usage by 92% for the first load by migrating to a PWA.
low friction of distribution - if your progressive web app is online, it's already accessible for Android (and other mobile) users.
65.5% of US smartphone users don't download any new apps each month
PWAs eliminate the need to go to the app store, search for the app, click Install, wait for the download, then open the app. Each of these steps loses 20% of the potential users.
Final note: PWAs run, with the same codebase, on the desktop as well as most mobile devices. On desktop environments (ChromeOS, and later Mac and Windows), they're launched in the same way as other apps, and run in a regular app window (no browser tab).
The main advantage for native applications is that they can access all native APIs a platform could offer (contacts, camera flash, SMS, telephony, network, bluetooth, sensors, raw sockets...) while a progressive web application can not (yet) as they are constrained by the Standard Web capabilities.
The goal for progressive web applications is to expand these capabilities to cover the most critical cases. In this mood, take a look at Progressive Web Apps: Escaping Tabs Without Loosing Our Soul where you can find a list of what a progressive web application should offer:
Responsive: to fit any form factor
Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
Fresh: Transparently always up-to-date thanks to the Service Worker update process
Safe: Served via TLS (a Service Worker requirement) to prevent snooping
Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.
From these points, linkable was one of the first characteristics imported by native applications from the Open Web in the form of mobile deep linking.
But special mention deserve the combo fresh + installable as it represents one of the main advantages of the Web as a platform over the native alternatives. Here installable means that it appears in your home screen. It does not mean you require to pass downloading and installation stages. You open a URL or discover a service while browsing and it's done: it appears in your home screen.
Fresh refers to how a regular web works, offering an instant load and seamless updates. You are not asked for installing an update from the web of YouTube, it is deployed and you consumes it the next time you visit it.
I'm not talking about the benefits of the remaining points because you were asking for the differences and, for instance, re-engagement is something native applications already have via push services and notifications and now web applications have caught up.
Other related and key question is about which platform is more suitable for your needs. If you are not accessing special hardware capabilities, the Web should be enough and choosing the web you are free from the marketplaces, proprietary ecosystems and by the way, you can ensure certain grade of ubiquity and interoperability.
As final notes, I recommend you to browse www.flipkart.com from a mobile with Chrome. It's pretty awesome: no bugs, smooth navigation, app-like feeling. Go offline and it will continue working. A truly real world example of that post. Add the app to home screen and next time you open it, the experience is even better.
You can take a look at Firefox OS as well as an example of bringing more platform APIs to the Standard Web (with more or less success).
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.
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!
Can anyone give a comparative information between developing Android mobile applications using Eclipse SDK and Adobe AIR?
Kindly share your opinion, anyone who has already having any experience on developing Android mobile applications using Adobe AIR.
I have gone through articles on developing Adobe AIR but wanted to know if anyone found it useful. I am aware that Android mobile applications developed using Adobe AIR is supported for Android 2.1 and 2.2.
Thanks in advance.
I will do my best to answer your question, though it's a little broad (if you could provide specifics on the information you need, I'd be happy to add more detail).
Firstly, there's a ton of information both from Adobe and from the Flash/Flex community on developing for AIR for Android. You can develop for AIR for Android using Flash and the Flash IDE or using Flex and the Flash Builder IDE currently in public preview on Adobe Labs (you can do straight ActionScript as well if you like).
One of the benefits of using AIR is that you can leverage your existing skillset in Flash/Flex/ActionScript rather than having to learn a new language. Another benefit is that yu can reuse code for existing Flash/Flex/AIR applications you may have built. Another benefit, and the one Sheikh mentions above is that Adobe is working on making AIR a cross-platform mobile runtime. If you search you will already find articles from Adobe and the community about people running AIR applications on the Playbook (the simulator anyway, since the device isn't released yet) and even using the preview Packager for iPhone to compile their applications to iPhone.
Although I haven't worked with AIR, but what I feel AIR is for, is cross compatibility.
Its like you're not building for Android, you're building for AIR. and since Android supports AIR, your applications will run on Android device.
In future more Mobile OS will start supporting AIR, so if you code an app for AIR, there will be a huge possibility that your same code runs on different platforms like Android, Windows Phone 7, iPhone (perhaps :-P). Thus, it will be saving a lot of coding effort for coders.
I have discovered that the cross-platform compatibility for AIR applications is quite good except for a few caveats:
1) User input boxes. They are generally not handled well in AIR applications. The popup keyboard can hide the input box, which it generally does not do with native JAVA apps for Android.
2) Real-time games. AIR for Mobile is SLOW. You may be disappointed if you try to develop any sort of real-time software.
3) Socket communication. This is my current peeve. I created a simple chat application in Flash and did some speed tests. This is in preparation for creating multi-player games for mobile devices. On the PC, the application can run over 200 messages per second to the server and get responses. On the AIR for Mobile, both on the iPhone and Android, it is about 11 messages per second max - and the app is doing nothing BUT sending and receiving the data strings. Add a layer of game play and the speed limitations could be crippling. This means real-time games may suffer if you need faster communications. It's plenty fast enough for turn-based or games that don't require lots of updates.
Basically, the cross-platform compatibility is nice. Just think about whether your particular project might be harmed by the speed issues as well as potentially poor handling of user input boxes. Do some testing.