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 8 years ago.
Improve this question
I hava an iPad app where I store data using Core Data (sqlite store).
The app would be sharing the Core Data store between authorized users on a per-app/per store basis; in other words, one shop buys the app, and has several staff members with iPads who want to access the Core Data store on their iPad for that shop. Other shops are have the same requirements, each shop having it's own unique Core Data store on a unique Google Drive, which would hopefully prevent one shop from looking/downloading another shop's data.
is this possible?
can someone please point me to the relevant docs that I need to get started with Google Drive API in my iOS app?
is there a way that the app can synchronize the data between iPads on a per shop basis using Google Drive?
If you want to put the Core Data in shop's Google Drive, there is a potential risk that the shop might accidentally delete or modify the Core Data, but anyway, this can be achieve like this:
In your app, ask for the shop account for appropriate scopes, then store the credential in your service so later when staff members ask for the Core Data, you can delegate the shop account to grant shop's staff permission to access the Core Data. In the staff's Google Drive the file will appear in Shared With Me.
Maybe you should use another account to hold all the Core Data for all the shops, for example your service account. When one shop buys the app, your service creates a Core Data for the shop, then adds permission for only the shop. I suppose you want the Core Data to be readonly, so you can grant the reader permission for the shop. When shop staffs ask for the Core Data, you do the same for them.
Now the shop and staffs can access the Core Data, you will want it to be in specific folder, so it can be synchronised to shop or staff's local devices, in your case, their iPads. You can delegate the shop or staffs account to create a folder for them. Then update or Patch the file's Parent to include the folder Id. The shops and shops' staffs will see the Core Data in the folder you create for them. This action will require a higher scope, say: https://www.googleapis.com/auth/drive.
https://developers.google.com/drive/quickstart-ios
Hope it helps.
Related
I'm working with some IoT projects and for handling all data I have used Blynk application but now I have created my own app but problem is that I want to add sensor data to firebase, but I have multiple users that's why I want to separate my data for every user, how can i do this, which Library is helpful for this? I have searched on Google for this, but everyone adding data in common database but how to separate the data for multiple users?
To separate data per user in your database, you will want to organize the database reference path to a location relevant to the user uid. if your app supports Auth, you can access this with the currentUser object which should have their uid as a property.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a website that customers can log into and buy products from a specific range (based on their customer number). The navbar has a dropdown for product categories, but doesn't show any where there would be no products.
At the minute, the database is queried on each page to populate the product categories menu, but this feels inefficient. I'm now wondering if the list of 'allowed' products should be stored in either cookies or session variables at the beginning of a session.
From what I have gathered from other questions, a session variable would normally be used, but they have warned against storing a lot of data in session variables. In this case, I would be storing a potentially large list of products for each user, so would cookies be better? I wouldn't class a list of products as being particularly sensitive, and I would do a server-side check before placing the order. Or should I stick with the current solution of querying the database each time?
To be clear, I will still store the information in the database as well, this question is only asking about a temporary storage for quick access throughout the session.
I have already looked at the following questions, but I still don't feel like I've quite got the answer for my particular scenario, and the questions that are close haven't mentioned cookies.
Cache VS Session VS cookies?
Cookie VS Session
Session Cookie vs Persistent Cookie
Trade off between user data in session vs database?
session variables vs database
The approach I would take would probably be something like this:
Store the product data in a cache that is shared between all customers and use the primary key of each product as (part of) the cache key for each product. The cache strategy used could vary depending on scalability requirements (System.Runtime.Caching vs redis vs file caching). In general, I would probably use a sliding expiration or LRU cache (see this .NET example) for the product data so the most popular products stay cached longer than less popular products. When a request comes for a particular primary key, the cache is checked first for the key and if it returns null, the product is looked up from the database and cache populated before returning the product (see this example).
For each customer, store only the primary key and other relevant data (what class of discount they may get, etc.). If the primary key list is small enough, you can probably get by with a cookie (encrypted) for this. If you need this to scale to give each customer more than will fit in a cookie, then query the database for the primary keys.
When the customer requests the data, get the list of primary keys first, then use those keys to access the pre-cached product data to build the view. You can store as many different primary key lists as you need to meet your requirements without having to get the product data from the database for every customer or every use case for an individual customer.
Think twice about using session state - the advice there is not to use session state for user profile data.
Of course, the above doesn't take into consideration any other marketing requirements that may be needed. So you may need to adjust this strategy for your needs. For example, if you need to update the product information faster than the cache would normally expire, you might consider an approach that updates the product data in the database first and, if successful, gets a write lock on the cache and updates the cache, too. That would allow for near-real-time cache updates without having to invalidate and reload the cache from the database.
I am looking for the proper way for a swift iOS app that relies on, in my case: AWS but has a local persistent data store so that every possible feature of the app can be used offline.
So far, I went from a pillar or two of Core Data to a full core data stack and it is becoming difficult to foresee how to coexist with AWS DynamoDB. While DynamoDB is of a NoSQL structure, Core Data in the way I have set it up is that of a SQLite persistent data store.
I need to eventually download tables and primarily use AWS for most situations where users are online, but if they want to work offline, I need to be prepared. Perhaps I should try to create a singular User entity, because why would I want to store other users offline? Then once internet is active, I could try to push it to my DynamoDB Users (plural) table.
I have created Entity's in Core Data such as Users, Authors, Profile.
In the scenario a user opens the app and has no internet access, I am planning on inserting a Users entity and my goal is to correctly populate Authors and Profile, because this offline end user is definitely a User, and I want to setup at least a Profile for them as well so that they can later tweak with customizations.
I have maybe too many relationships. I want to do this correct.
In simple situations, I understand a Person Entity might have a father, mother, child and how they can all fit nicely into Person, but since I have entities with enough unique attributes that I thought I need to create their own entities,
How should I go about creating an entity that certainly makes a User/Users record and establishes a Profile?
Short answer is this:
Core Data is your local cache whether you are offline or online. If you are online then the app should refresh the Core Data cache when appropriate.
When offline the app should not update the cache.
The User Interface in either case is identical. The user interface feeds from the Core Data cache ONLY.
I suggest watching my talk on MVC-N that is hosted by realm.io.
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 8 years ago.
Improve this question
I am creating one application. This application have two databases.
Local Database (In the mobile)
Cloud Database
Both databases are automatically syncing.
Through my application when I Browse the page I want to keep that page in my phone. again When I browsing without internet (Offline) I want to access that store files.
My problem is without internet offline browsing (stored web pages) need to access my local database and give the informations.
Eg. I want to search something. if it is internet search cloud database. (Same time store the web page HTML content in the phone). Offline searching want to access the local database. In here it want to use the stored HTML content. But access the local database.
It is possible or not? I am a beginner. Please guide me
You use scripts/code on server to connect to db on the server when you are online. Even if you download and save you 'HTML' file locally, when you load it in UIWebView it is not going to start fetching data from your local sqlite db. (hence all the down votes i guess)
So simply put, what you are asking is not possible.
However, an alternative which may work, subject to your app requirements, is to change your app code to always perform searches on local database and instead of HTML show search results using native UI. As you claim that your local db syncs with the sever automatically, when you are online, after your db is up to date, your search results will fetch fresh, synced up data from local db. Since your search uses local db you'll be getting last synced data when you are offline.
I am about to build an internal-only iOS app for storing simple business data. The data store will consist of a single entity only, with one entry per day. To start with there will be around two years worth of data (~750 entries).
I want to set the app up to do one-way syncing only. i.e. Only one person can enter data, but others can read it. iCloud is out as it only works for a single user account.
Is there a lightweight way to sync this datastore out from the single write user to the other read users? Setting up a full sync system seems overkill for this case.
Instead of iCloud, you could use one of the online backends such as Parse.com or Simperium. They would allow you to share data using a db and also provide for user accounts, authentication etc. If you want to run the server locally you can investigate DataKit.