I am using an IOS app with a Rails Back-end. When the user opens the app, I want to query its profile from the server and set a current user method in order to call it somewhere else in the app without querying it again from the server.
I would also like to store it so that the profile is saved to the disk and can viewed offline, including the profile picture.
What is a good storage solution for the current user and its profile picture? The different solutions I am thinking about are Core Data (because I already use in the app), and NSKeyedArchiver.
Any recommendations or ideas on which solution to adopt?
Related
I'm in the final stretch of building my first iOS app and I wanted to know the best practices for passing around the user or not. Do I pass the user to every controller or is there a store-like infrastructure I can set up to store all runtime data in, or do I fetch from local storage every time I need the user?
Also when I close my simulator, the user is logged out of my backend. Does that mean that I should store the user password in local storage to sign them back if they have logged in before or is that bad practice?
If these questions have been answered else where please send me a link to a discussion along these lines.
I'm building a simple iOS app that will be the first I'll have put on Apple's App Store. At one point, the app accesses the user's contact list and lets them select any number of contacts they want to save as favorites.
For ease of building version one, I am currently using UserDefaults to save these favorites. While it has worked well in my limited testing, I know that Core Data and CloudKit are stable options for larger solutions.
For an app like mine, where I'm only using UserDefaults to save a select number of contacts as favorites, is UserDefaults an adequate solution? Or should I transition to something more robust like Core Data or CloudKit? There is no limit on the number of contacts a user could select as a favorite, so there is the edge-case possibility of a user selecting all of their contacts one by one and attempting to save them all as favorites.
If the user gets a new phone and loses all existing data due to UserDefaults being local on the device, it would not take long to get this app back to where they previously had it.
You can use CoreData to store favorite contact locally for large data as per your concern. Now when user switch device or delete app then all data will removed. So for that you can sync with cloudKit or other option is backend server. When user add any contact as favourite same time that contact will add to Core data as well as in backend server. You can sync this backend server data when user login first time in the app, then you no need to sync again. other all thing are as per requirement.
I'm trying to find a way of letting a user store their photos/documents online for my app. They can upload these to the app after registering an email and they remain on the phone even when the user logs out and then in again. However if the user deletes the app, downloads it again (the developers are using TestFlight at the moment), and logs in, any photo or document that the user saved before deleting has vanished.
I've been told that the data hasn't been stored on the Kinvey SDK service that we have been using as it takes a while to upload the data and then was told the app would be better suited on Kinvey REST API as the SDK version doesn't support background mode which supposedly would help store the data quicker (but this still wouldn't be 100% sure the photos/documents would be stored)
I'm not a developer/coder so I'm afraid I don't know much technically but my app needs to be able to have access across devices for the user's photos and documents, if these are 'lost' it would be catastrophic.
Please could someone help me if there a way of doing this?
Thank you.
Well If you want to save pictures or data that do not get deleted here are few options.
Save them iPhone,iPad gallery if not the use REST API
"Kinvey" can be used for that.
The alternative of "Kinvey", Kindly look into this.
https://www.raywenderlich.com/126098/top-5-parse-alternatives.
and may be you can try this. It provides chat feature too.
http://quickblox.com/
A number of iOS apps I develop are used in scenarios where the Organisation has a number of Drivers and the iPhone is shared between them. Each Driver has his own app credentials, logs in to the app, and is presented with his own set of data. The Firebase data is persisted as he is offline most of the day and I use keepSynced(true) to ensure data is up-to-date.
The problem I'm having is that once a user logs out with the Firebase method FIRAuth.auth()!.signOut() then when a different user logs in, he sees the previous users' data. I'm guessing that because the data is persisted it is not cleared from the cache. However, I am retrieving the data by the user id so this doesn't quite explain it.
What is the best pattern to permit multiple users to use the same iOS app with Firebase ?
Try creating multiple instances of FIRApp, each with a different name, using the +configureWithName:options: method. Then use the different apps in FIRAuth +authWithApp and elsewhere as needed.
I haven't actually done this and am too new to Firebase to say it's the best pattern, but it seems like it should work.
One thing to note from the docs is that, "On Android and iOS, Analytics are only logged for the default app." One solution might to keep the __FIRAPP_DEFAULT app, and then make a named app for each user type.
I have an app that is uniquely branded for each customer (think restaurants, etc.) I need to have the user be able to click on a link to my server that contains a unique code, stores that temporarily on the iOS device (cookie, etc.) and then directs them to the app store to download the app. Then when it is downloaded, the app grabs that cookie or temp. data on launch and brands the app for that customer. I know this is possible on Android, but is it on iOS?
Downloading the app first and then selecting the brand (or restaurant) is not feasible in this case, as the url wil be shared with other customers of the same business and we want to create a fluid experience, where they won't be able to "see behind the scenes" and choose a different branding.
Thanks
Edit
Thank you for all the replies. We've reevaluated and are considering having the url be opened on the device and grabbing the IP address or another unique id, and saving that along with the correct brand to a database. The app will then connect to the database on launch, and if the IP's match, will brand accordingly. We're looking for a more reliable identifier than IP, however. Now that UDID is deprecated, are there any other identifiers we can use?
I think the design you propose of a webserver link creating the code that needs to be read by the iOS app later is the issue. You should have a solution that is entirely app based. Perhaps you can have the same services on the website be available as one app which then sets up the code in pasteboard. The user then launches the actual app that looks at the pasteboard and skins itself accordingly.
That being said, data can be shared between apps from the same app seed ID by using UIPasteboard in addition to a few other ways.
I use the pasteboard to share info between apps quickly and easily using this class.
You can use identifierForVendor (UDID replacement) to identify individual devices. Are you planning on harvesting those identifiers prior to the end user "registering" the device at the final location? If not you'll never be able to determine which device belongs where.
What about having the end-user logging into your server as that restaurant? It can be a somewhat generic login per restaurant like "Wendys/Wendys5?" and "McDonalds/McDonalds7!" to determine their App Store URL. As long as the password is easy and non-programmatic to guess it would be unlikely they figure out how to register as a different restaurant. You could also do a simple restaurant selection screen coupled with a password specific to each chain but this would expose the user to which other restaurants are using the app. This way you won't have to continually add IPs if they expand locations and can revoke credentials if the login is compromised.
One question, though: Do all of your clients understand that they'll have to have an AppleID tied to each device? You can only shared a single AppleID across 20 devices.