I have downloaded offline map and with MapEngine.setOnline(false) to make it working offline with that area, the map can be shown, but when I try to search some location, the suggestions list are very less than with online map, is that supposed to be so or anything wrong with my settings?
If you truly want complete offline operation, yes the search results will be limited when operating in offline mode (i.e. MapEngine#setOnline(false)). The offline search database is limited compared to online.
If you don't require being fully offline (i.e. no data being used whatsoever) keep in mind that simply by preloading the map data as you have done, far less data will be used by the HERE SDK during normal operation, so you can not call MapEngine#setOnline(false) and still allow Routing, Search, etc. to go online to get better results.
If you want to keep the SDK offline but only allow Search to go online, you can override the global (MapEngine) setting when making search requests by calling setConnectivity(Connectivity#ONLINE) for your search Request objects.
Related
I'm building an Android app which syncs data to Google Fit and uses the Google Fit SDK to achieve that - but I'm pretty sure my question also applies when you are using the REST API.
Within my app users can also change data inserted to Google Fit. The Google Fit SDK has two distinct functions to handle those kind of things: insertData() and updateData().
Now, I don't want to keep track of whether a user changed an already synced data point vs whether it is an entirely new datapoint. I just want to have a simple Boolean flag which indicates whether a data point has already been uploaded to Google Fit or not - that's to keep things simple and reliable on the app's side.
So when a user creates a new data point in my app, I set a syncedToGoogleFit flag for that data point in my DB to 0. When the data point has been synced to Google Fit I set it to 1. When the user later changes the data point in my app I set it to 0 again and so on.
However, the Google Fit SDK distinguishes between inserting and updating which means a simple Boolean wouldn't be enough to track changes on my end as insertData() will fail if there already is a data point for a given timestamp. Is it possible to always call updateData() even if I am actually inserting new data and that way get by with just the Boolean flag on my end?
Looking at the documentation it should be okay, but I would feel safer if someone could confirm that. Also I'd like to know whether there are any potential performance implications of the approach outlined above, but I guess this is just something the SDK devs can answer.
I've played around quite a bit with the SDK now and from what I am seeing I can say, that using updateData() seems to work just fine.
I'm writing an android application that has a search feature that needs to autocomplete from a list of stores. This list will only have up to a few thousand stores in it.
My current methodology is to send a LIKE query to the database every few hundred ms after the user has stopped typing and to populate the autocomplete list with these results.
Would using this method be stressful to the database?
It has been suggested to me that this wouldn't work because making continuous calls would be poor for users with a slow connection and that I should load all the stores into memory and filter from there.
At my work I ran into a similar problem a few months back. The contents of a text box filled by the user were supposed to filter their available options to choose from in a list of strings. The list needed to be updated every time the user typed a key so database calls to fetch records that matched their text were being made several times a second.
This ended up being wayy to slow to update as someone was typing, and this was only with several thousand records and with a server that was being accessed on site.
If you want to update as quickly as someone can type, making that many database calls simply won't do. Users will get pretty antsy having to let their phone buffer to type in some text.
In Short: Make one databse call and load it up onto the phone, and run your filter algorithm from there.
Regularly syncing the list of stores from your back end to the user's device and implementing autocomplete locally is the best way to go.
The JobScheduler API provides a flexible way to set constraints on your background syncing processes.
I am creating one Google Fit compatible App. My objective is to store Google Fit data using HistoryApi, and provide kind of Back Up- Restore functionality to user. If user buys new Android devices then he/she should be able to BackUp(sync) old data using his/her account.
I need to use Custom Data Type, as Public Data Types doesn't meet my requirements.
Everything works perfect, I am able to insert data and read data using History Api.
But When I try to read data from Another Android device using same Google Account then data is not available to read there.
My problem seems similar to this Custom DataTypes not synching between devices
This statement from Google Fit Document is not clear to me.
Custom data types are not available to use in other apps. Only the app
that creates a custom fitness data type can use it
source : CustomDataType
Q-1) What does it really means ? If I have an app GoogleFitDemo installed on multiple Android devices, then is it possible to sync data between this same app between multiple Android devices ?
Q-2)Is it improper way to store and backup data using Google fit ?
Update:
Finally, I found that Custom Data Type can also be synced normally, same as other Public Data Types. I had the sync issue as mentioned by #Ifor. Sync functionality is still buggy. In some scenarios sync stops working, and sometimes synced data is inconsistent across multiple devices.
1). My understanding is that same app same account but different devices it should work. Having said that sync is notoriously slow (hours days...) and has been buggy so it may be hard to tell if you have it right or not.
2) There are better backup methods... But if the data fits in with the rest of the stuff Google Fit is about and is not too big then it's probably ok.
I wanted to venture into making apps. I wanted to make an app that gathers the events around the user location wise. I want the app to show the events close to user using the GPS of the phone. There is a city page where all the events are listed but I don't have any ideas how I will be able to fetch the data. What are the other ways I can go forward with this? It would be encouraging so that I can research further.
try this
http://www.last.fm/api/show/geo.getEvents
login this and get the api calls and use it in your code
i think you can use a combination of api's to give you the data you are looking for, one such provider i found was http://api.eventful.com/, you can probably even try including foursqaure and meetup's api and even facebook opengraph event api can also provide some handy data.
I got an application that displays some items loaded from a webservice (e.g. Fruits). These items rarely change. You can also show availability of those items (e.g. for apples, 10kg is available at store A today, 20kg tomorrow, ...)
The user can bookmark some of those items on his phone. I need the user to be able to bookmark some of these items and to have his bookmarks synchronized between devices (I bookmark apples on my phone, I expect to see apples bookmarked in my tablet next time I open the app there).
More or less, I got around 40 items, no more. And each availability data would total to around 200 entries.
Which technique would you use to implement that?
My idea so far:
I build a sqlite database (with contentprovider) of fruits and availabilities
I synchronize this DB every 2/3 days (that is enough, no need to do it more often)
I use a BackupAgent to synchronize the whole DB file
Do you think a database is overkill? The application is expected to always be ran with network connectivity (else we don't allow it).
My other option would have been:
Load items and availability on application start
bookmarks are kept within SharedPreferences
I use a BackupAgent to synchronize only SharedPreferences
This seems less complicated, and more efficient on the sync part. However, I feel that is not really a clean way to do it and less future-proof.
Android's backup API is only useful to initialize a new device based on the backups created by another device. See the backup API docs. It is not the right infrastructure to keep 2 devices in sync.
I suggest you take a look at the Cloud Save features of the Google Play Game Services. It allows you to sync data on two devices. It is typically used by games but can also be used in other scenario's (like yours).