I'm using HERE SDK on an Android heads up display device which only has a Bluetooth link to the internet. This internet link is therefore very slow, and somewhat unreliable.
Traffic and even live maps information seems to work pretty well, however it's impossible to update offline maps with this, they're too large and time out.
The device appears as a USB drive when plugged into pc which has the here maps offline cache folder directly visible. I've been able to test that copying the cached offline maps folder downloaded by a different here maps app on Android onto the device works to update the maps, but it's very slow and tedious.
Is is possible to update the offline maps cache from any web service / desktop app outside of the Android/iOS sdk libraries?
Currently, there is no way to store the offline maps data into PC storage and we have to use mSDK Premium version to use the offline mode based on the offline maps data.
Additionally, the downloaded offline maps data needs to be updated when there is a new version in the HERE backend server and it is handled by HERE mSDK.
Related
We have a client interested in our app, which relies on Firebase. However, they want to use this while they are out to sea and won't be able to connect to the cloud.
They do have a local server and a local wi-fi network.
Does anyone know if using the Firebase Local Emulator Suite would be a practical solution to this problem?
The Firebase Emulator Suite is for development, not sure production use. From its documentation:
The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally
So it is (currently at least) not suitable for using in the scenario you describe.
What you can do is look at the offline mode of the various Firebase products, to see if they fit your needs. I recommend checking the documentation for each, or this handy video that covers all of them: Firebase offline: What works, what doesn't, and what you need to know.
I haven't had much success searching for this. I'm developing an Android Things application that will connect to a user phone to do certain things. I want to use this for delivering app updates as well.
So far, my crude searches on this have just discussed OTA via the Console and thus internet.
My gut has said that I could just build this - I could have a new version of the APK, transfer it to my device via bluetooth, and then just have the device copy it over the old one and reboot. But, not sure. I was hoping maybe there was an API for this and I'm just not wise enough to know how to find it via the searches.
since I am new in the world of developing apps for watches, and the fact that it exists for smartphones the following frameworks:
Xamarin
PhoneGap
appcelerator
kony
Cordova
...
I wonder if there exists for watches apps similar frameworks? So that you code once but run overall.
Thanks
Edit 1:
At this day (12.05.2015) regarding to the answer of a nativescript maintainer here. I will go with nativescript to start writing app for wearables.
Cordova/PhoneGap apps don't work directly on the wearable devices/watches. Cordova/PhoneGap is basically a javascript API which can run on WebKit/WebView on all the mobile OS's. But the Android Watch and Apple Watch doesn't support WebKit and so the apps developed with Cordova don't work directly on Watch devices. But if want to extend some of the features from the existing Cordova app to the wearable app, you need to create the extension app in native language and the extension should be able to communicate with the paired app on the mobile device. The extension on the Watch will have only UI and the bussiness logic etc runs on the Cordova app on the mobile. It is possible to establish communication between these apps which will drive the display on the watch devices.
I am not sure about the other frameworks you listed above on how much they support wearable devices.
As #kiran and #NRimer have mentioned, these cross platform frameworks are relying on the WebKit/WebView which is the almost universal layer supported on every mobile device. They dont run directly on the device, but device runs WebKit platform that runs these cross platform apps. So comparing the capabilities of the native app with cross platform app, native app is bigger, because it can have a hands on device hardware related features. The thing particular to the smart watches is that they mostly rely on other smart phone device, and it uses it's communication protocols, that are hardware specific, and WebKit doesnt have its hands on it.
It depends on what you're looking to do with the framework. Watch apps build off data provided by their containing app. For example if you want to provide custom notifications on the watch, the app (or server for remote notifications) constructs them. When your watch app needs information, it makes a request to the containing app. Lets say you have a group of apps that you want to provide the same notifications or functions on each of their watch apps, you could make a framework that handles these functions for the containing app. As for the watch portion, think of it as more of a display of information provided. Unfortunately i dont think there's a way to generate frameworks for watch apps yet. If you're looking to have a lot of code within the watch app this might be more difficult but for simple display of information you should be alright.
I talking about Native Client thing for google chrome...
Developers claim it can run native code compiled from c / c++ in browser's sandbox.
They describe a lot of things, but never point at what I need... So, if I create window in my application with CreateWindow, would this window appear when my Native Client application loaded into browser?
In short, no. Two key things to know about apps that use Native Client in Chrome:
They are platform independent (platform-specific calls are
disallowed).
They are still web apps with the restrictions and possibilities that come with that.
If Native Client allowed operating system-specific calls like CreateWindow, it would no longer be platform independent (and it would also present a security risk).
Instead Native Client provides a set of platform-independent APIs called Pepper or PPAPI that work the same for all supported operating systems (currently that's Mac OS, Windows, Linux, and Chrome OS). As mentioned, apps that use Native Client are still web apps, so Pepper gives the same possibilities and restrictions that you'd expect from JavaScript. E.g., you can fetch URLs or ask the user for fullscreen permission, but you cannot access any random file from the local file system (app-specific isolated local storage is possible; as is having the user upload a file for the app to use).
Moving an existing C or C++ codebase to Native Client is very much like porting to a different operating system. Instead of using, say, Windows API calls, your app should use Pepper API calls.
For additional background it may be worth noting that Chrome Packaged Apps can request access to a much wider set of APIs in the chrome.* namespace. These APIs include USB, sockets, opening new windows, and more. A Chrome Packaged App will still not be allowed to make OS-specific calls, but they have access to quite a few more APIs, all of which are platform-independent.
In short, if your app can be made to work with the Pepper API plus the chrome.* APIs, you could write it in Native Client and JavaScript, and you'd have an app that worked the same way across the four operating systems mentioned above. If your app cannot be made to work with those APIs, Native Client in Chrome is not the right choice.
Seems not.
This is a bit related: http://ssj-gz.blogspot.com/2013/01/emscripten-qt-progress-faster-better.html. It's translated to javascript, though, and only for QT. And slow.
I want to embed Ovi Maps in a desktop application in offline(but interactive) mode. GIven that these maps and their related map APIs are mainly targeted for mobile platforms, is this possible ? If so, can anyone point to any existing documentation on how to do this? Any pointers to existing examples would be a plus.
I considered using google Maps which can be integrated with desktop applications, but they cannot be used in offline mode.
Unfortunately, even if you can use Ovi Maps in your desktop application (using Nokia Qt C++ SQK with Location API, see http://doc.qt.nokia.com/qtmobility/location-overview.html) you cannot use Ovi Maps in offline mode and there is currently no way to embed it (offline maps use is only possible on Nokia mobile devices that embed maps by default).
Regards
The latest branding of Ovi Maps has changed to Nokia Maps. The new - Nokia Maps Framework for Mobile HTML5 claims to have offline support. The API relies on the user using a browser which supports local storage, so provided your user base is using Google Chrome or Safari it would work on a desktop as well as various mobile platforms.
An example app can be found with the documentation
The offline claim can be found here