I am currently developing (my first ever) iOS app using firebase and testing with a small group of users and everything is going fine (because I am hard-coding the org code into the ref builder). The app is structured around having autonomous organizations with its own users hidden from other organizations. The problem that I am running into is how I structure my model so that it is possible to access and it is efficient when it starts to add new organizations and users.
specific problem:
Org names are dynamically created, so my login pattern needs to be able authenticate the user in Firebase, then retrieve the user's data stored in the database under their specific org code. I can't figure out how to save the org code for login each time the user opens the app so they don't need to type it in. Technically I could pull down the whole the database to find it but that's the worst possible solution. Would I maybe need to use Core Data?
-_admin
-org1
-name
-availble_licenses
-used_licenses
-org2
-org3
...
-org1
-users
-$uid
-name
-uid
-email
-$uid
-$uid
...
-org2
...
My answer is based on this assumption
I can't figure out how to save the org code for login each time the user opens the app so they don't need to type it in.
For this, you don't need Core data but UserDefaults. Core data it's for a huge set of data. On the contrary, UserDefaults, it's useful to store tiny data. It's like user preferences :
The UserDefaults class provides a programmatic interface for interacting with the defaults system. The defaults system allows an app to customize its behavior to match a user’s preferences.
So you can use it to store the org code for a specific user.
Here is a tutorial on how to use UserDefaults : UserDefaults
Related
I have multi-vendor project which some variables should set by admin, For instance when User wants to pay his/her cart, fee should be specify and it defined by admin of system. (And it could be change passing of time.)
So what's the best approach for keeping this variables?
Note:
I'm running server with Nodejs and I use MongoDB as database.
I have following ideas which has pros and cons in my opinion:
Save these variables in document (in database), which I guess it's not good since I have to for each payment (or other actions which need these variables) send request to database. These variables seems to be fixed and can change after a while. I mean it's not like a user profile information which could change
frequently and when user wants to see his/her profile request should send to database. (further more it's just seems not good create new collection for storing just a document)
Save this in .env file (as environment variables) and I think we keep configuration variables in this file (application layer, not keeping the variables for business) and also updating this file is not good as database.
Please aware me if I make a mistake or there is common way which I don't know. (Also I searched for that and I couldn't find any proper keyword : ( )
My approach has been the following:
If the values can be updated by business administrator in normal course of operation - then they should have Admin UI and be stored in the database. Fees are a good example.
If the values hardly ever change; or changed by IT staff - put them in the configuration file. Endpoint of Vendor API, or mail server configuration would go there.
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).
I am building an extremely simple VB.net web application that uses Visual Studio's forms authentication. As part of this- I am trying to capture the userID upon login and use it while the user is in the app (to dynamically display information via dataset/gridview that is associated with that userID) so I don't have to give them their userID and prompt them for it constantly.
The app is very simple and uses a local DB to do all the authentication (Users, User_Activation, Roles)
This app will have 9-10 users that will be consistent over the years(logging in 10-15 times a year), and 40-50 rotating users that log in once or twice and do not return past that year.
The profiles and authentication/sessions do not need to handle tons of users and authentication requests.
I also want to avoid cookies because I want to keep everything as simple, and centralized to the application as possible.
I have explored building a GetUserID function that queries the database based on the userName every time a user takes an action (button click, page load) that requires the userID. But I am having trouble with the SQL and it seems bulky.
I have also looked into sessions- but they seem unreliable and difficult to manage.(How do i keep each session separate as users login?)
I am now looking at Profiles
https://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
https://msdn.microsoft.com/en-us/library/system.web.profile.sqlprofileprovider.aspx
I think I can just use the default instance of the SqlProfileProvider and point it to my database I already have built?
I am very new to programming and am not sure how complex the configuration would be for the Profiles, so any guidance or advice would be greatly appreciated!
I can post any code snippets needed, or upload the app to github or something if that helps at all.
Thanks!
What I'd like to do is on the first load of my app, ask the user some questions. The answers they provide will be used to set the organization information that appears throughout the app instance.
For instance when the app loads the first time I'll ask; "What is your organization name?", "What is your organizations phone number?", "What is your Stripe secret key" and more questions like these. I'll then use that information to populate receipts and contact information that appears throughout this app instance.
Normally I'd use the settings.json file to populate this information and make it easy to drop in these pieces from anywhere in the app. I don't want to expect that the user even knows how to use Meteor and so I don't want to use the settings.json file.
Save those values to the user profile. If 1 organization has many users & they all share these values, create a collection like organization and save the values there.
I'd like people to be able to initially use a meteor app without explicitly creating an account until such time as they wished to share their data or see their data on another device. Even when they were happy to explicitly create an account, I'd like the option for that user account to be passwordless (i.e. https://passwordless.net/).
But I'm struggling at the first hurdle. How do I check that a user account doesnt already exist and create one if necessary?
There are a few packages which look promising:
https://github.com/artwells/meteor-accounts-guest/
https://github.com/tmeasday/meteor-accounts-anonymous
If neither of those are exactly what you want then they should at least provide a good starting point.
An alternate would be to use accounts-password and automatically create a unique user account for the guest once they perform some important action so you can store their data. Store the login credentials for that account in localStorage (or a cookie). Then once they are ready to signup, move their data from their temp account to their real account and delete the temp one.