I'm looking to build a new app for in-house users (employees) and want to try out AppSheet. However, I really want to collect telemetry (usage) data so I know who is using what, when, etc.
I don't see any information about this, even after searching here and the wider web.
Is it possible to collect usage data from users using AppSheet?
Related
I am so happy that I get an ID per device, so I can keep data per user anonymously with firebase! The only thing that could be better is if I could get an id per user's iCloud storage for the app.
I understand that how the authentication token is maintained per app, at least on the web, is that it is stored in local storage. It implies that a similar approach is being used per app in iOS in something like UserDefaults. I'm hoping there's an easy way to keep it instead in NSUbiquitousKeyValueStore.
edit with use case:
I have an app that is (with permission) capturing and anonymously collecting location data. I would like to have that data stored per user rather than per device, and I essentially can't use signed logins.
(actually, the reality is that I am not capturing that in firestore, I am capturing accompanying metric data from other apps designed to work with this one)
So "why anonymous?", right? I am collecting time series data for third party apps - this presents risk of "use" to the user, and loss of control for that same data for the subscriber apps using the service I am writing.
Honestly, at a later point in time this might be converted to a library that allows apps to swarm their information together instead. But there are overhead concerns, and difficulty in trust for sharing data, with that approach and for my research project that approach is further from topic.
I want to store data of all page views on my site in InfluxDB and later I will need to get some analytics info about it. For example, "How many views does post X have?"
The problem is, as I understand it, if I have table page_views with tag(url) that is highly dynamic then I am going to have memory problems.
Right now I store this data in MySQL, but I am starting to face some problems as sometimes I need to store a 1000+ data requests per second.
So is InfluxDB the right tool for this kind of job? Is there some smarter way of storing each page view without tagging the url?
I understand that Core Data is essentially a self-contained local database, but I'm not sure if I should be using it in my app or not. Basically, it would be more for caching purposes if anything, since I retrieve all of my content from a web server database. Regardless, I was wondering if Core Data would be useful is any of these situations:
Scenario #1: I retrieve a list of "items" from the web server and feed them into a table view. This is essentially the first page the user sees. The table can be refreshed to retrieve more results, but existing items likely won't change. Over time this list of items could grow tremendously. Items can be deleted.
Scenario #2: A user has a friends list. This list of friends will stay the same unless he or she adds more friends. I imagine there will be a scenario where a friend deletes their account, in which case the friends list will be altered as well.
Scenario #3: Messages can be attached to items. They can't be edited or deleted, so the only change in state for a list of messages would be if a new message was added. Essentially the same as items, except they can't be deleted.
Actually, for your scenario I would say that you don't need any persistence in your app, but rather fetch your data from the server every time the app starts and just keep it in memory. There are a lot of apps which are doing it this way and this is totally fine behaviour.
However, there are some drawbacks of not using persistence:
worse offline experience for your user since they depend on a network connection, so effectively without a connection they can't do anything within your app
risk of slow loading
On the plus side we have:
using Core Data in your app is a huge implementation overhead (especially if you haven't used it before)
after having integrated Core Data, you still have a lot of issues to tackle, first and foremost: data synching between your app and the backend
If you decide to go for persistence, also take a look at alternatives to Core Data like Realm.
Finally, my advice still is to not use Core Data in your situation. However, keep in mind that you can build a version of your app that doesn't use persistence. And then, once you see that your app is well-received and gets more attention, you can still go and add persistence later on.
We have a requirement to be able to store the data on device and make it available even when device is off network, and when device comes back to network it should be able to sync the stored data and be able to update the stored data with latest server data and so on. I understand that lots of this needs to be implemented using sync/notification/versioning stuff ourself.
However are there any recommended framework/API (other than vanilla Core Data) that people use to store large amount of data to be stored/cached on iOS devices? Any reliable and intelligent caching solution out there?
Any recommendation of this sort will be very helpful.
My client states in an iPad app brief that the data (i.e. products and images) must be taken from an online source and saved. However, the app must also have an offline mode which shows this same data from when the app was previously online for times when internet access is not available (kind of like an offline reader). What would be the best way to tackle this? Any help greatly appreciated.
Download the data when the device is online and store it locally using whatever mechanism seems most appropriate (SQLite, Core Data, property lists, your own file format, etc.). Use this cached data when offline, and when online too unless it has changed. Create some mechanism that you can use to detect and download updates (preferably just the changes) when online.
This will be a big help for your users not just when they're offline, but online too. 3G data plans for the iPad are usually limited, so the better you can avoid repeat downloads of large resources like images, the better for your users.