Which activity should come up first? defined as launcher? - android-activity

If I have a login screen and then the activity which displays the main functionality of my application.
Which one should be deemed as the default=launcher activity?
Should I have the login screen as launcher which will be skipped if the username/password exist in the preferences?
Or should I have my Main activity as a launcher which should start the login activity if no user/password are present?
I have found the following google guiding lines:
http://developer.android.com/guide/practices/design/seamlessness.html
Look at the title: Don't Overload a Single Activity Screen
I am not sure that I have understood it correctly, but if I did, then it means that the login screen should be the launcher screen.
Am I correct?
What do you suggest?

this is a common sense what to do.
On successfully login save username and password in sqlite database or save in SharedPreferences. and check data allready exist in side oncreate() method og Login Activity
if username and password exist in SharedPreferences or sqlite database. start your activity in which you have main functionality.

Related

Auto Login using flutter when using FirebaseAuth

I want to auto-login every time the app starts, I am using FirebaseAuth, so my userid is auto-fetched, but it goes to the registration page directly, I want to check if the user exists or not if it exists, move it to the home screen else to the registration page.
I know what to do, but where to check this and so navigation?
What you're looking for is what we usually call a Splashscreen.
That's the screen you usually see on huge app's startup, with a loader.
On this screen, you can do all the stuff that is required for your app to run correctly :
Preload your images.
Load some datas from an API
Check the user's state
That's the good place to choose to redirect your user toward the most appropriate screen

User is not signed out even after FirebaseAuth.instance.signout is executed

I have a streambuilder that listens for auth changes. When i sign my user out using FirebaseAuth.instance.signOut(); it does seem to work. However, when i try to login with another user's credentials, the previous user's information is displayed instead.
However, I have noticed that when i hot restart my app in Android studio, the app resets itsefl and only then it presents me the new user's information.
How do i fix this?? It seems like my app's state needs to be reset after i signout, but I am not sure how to do this.
I am not storing any user value using shared prefs via provider, however i am using sharedprefs to store other information that helps the user filter information from listings.
Please advise.

What is the best place to setup apps initial version checks or load initial data from database

What is the best place to set up apps initial version checks and update shared preferences or load initial data from the database in flutter apps?
Because I want to update some shared preferences on app load, even it's from the background.
I usually use this logic:
To let the app startup be as fast as possible I do all checks in in first page after user log in.. usually that page is my main page.
So I do this
splash
check preferences and if there is a user I log it in
after login sucvesfull I go to mainpage
if there is no user in preferences I go to loginpage
first method in login and main is where I check versions, do user login ecc
So you can let user open app super fast and only after app is rendered I do checks.. so user has the impression your app open app really fast.
Bye :)

Launching application with different Activities at different situations

I am working on an application where I have to launch activity asking user to enter login and password to proceed further. The user will get option to save login/password. If user saves login and password, the application will not show login activity at next launch and instead should go directly to the main application screen.
I am thinking of starting application with Application class object and checking stored preferences to decide which activity is to launch. For some reason, application class is not launched, it may need some extra thing in manifest file.
Any suggestions what would be the best way to implement this kind of behaviour.
Thanks
Bsengar
Any suggestions what would be the best way to implement this kind of behaviour
A splash screen is often used for this. Your first Activity (splash screen) can display your logo/and or play music or whatever while you check your data and decide which Activity to go to next like login or main Activity. This usually shouldn't be displayed very long (maybe less than a second or so unless doing network stuff such as authenticating/loading data).
...and checking stored preferences to decide which activity is to launch
This is often how people handle this. You can check SharedPreferences in your splash screen to decide which Activity to start. If the login is stored then go to main Activity. If not then go to your login Activity.
Make sure to call finish() in your splash screen so if the user presses the back Button from login or main Activity they will exit the app instead of going to the splash screen again, unless of course that's what you want.
Good example of getting started with SharedPrefs in case you aren't familiar.
Full Docs for SharedPrefs
I wrote an application that does something very similar. In my case, I use a "remember me flag" that allows the user to indicate that they want the application to save the login id and password. If they elect this setting, the application will save the login information in preferences and pre-fill the login screen the next time the user launches the application.

Correct flow to log in user from iOS app to remote API

Here's the logic flow I'm trying to code into my iPhone app:
I think I understand the technicalities to achieve this (using AFNetworking, connecting to a Rails API using Devise as authentication). The auth_token will be stored in the keychain once the login is successful. What I can't figure out is the best way to go about setting up my app to behave like above.
I want the experience to be good for the user of course, so maybe while it's checking for the token and attempting to login it shows a "loading" screen of some sort.
How would I go about achieving this? I don't know which view controller I should set as the rootviewcontroller in the AppDelegate or how I should set it after the user has logged in. I've tried this in the Facebook app and when I open it I see a blank navigation controller it seems, then my profile view is loaded. What are they doing behind the scenes and is this the best way to go?
I am not using Storyboards.
I have implemented a similar one, the RootViewController was a "SplashViewController" in a navigationController, showing a nice logo, activity indicator and gives user info about authentication status. It holds the logic for checking stored token there and authentication implementation. If authentication is successfull, ShowUserController is shown by pushing to navigationController stack.
If authentication is failure a LoginViewController is presented modally. SplashViewController implements the delegate of LoginViewController, which does nothing but passing the username and password to SplashViewController. On successfull login, LoginViewController is dismissed and user is directed to ShowUserController.
Start your app with the root controller as the one that the user will see after they have logged in successfully, then layer the login views/controllers on top, with modal calls. If the authentication is successful, your user will already be where they want to be, else you call the login layers modally on top. Once they're authenticated, you won't need the login views anymore.
To elaborate on #Owen Hartnett's answer since this text won't fit in a comment; This is how I've seen Facebook's SDK work. If you build an app that uses the Facebook iOS SDK as the only login mechanism, then the way it works is like this:
In my app delegate's didFinishLaunchingWithOptions method I first check for an "already on file" access token in say, NSUserDefaults. If not found, I need to get one and so have my app delegate immediately launch a modal login flow that finishes with a valid access token that is then saved to NSUserDefaults for use on next app open.
If I do already have an access token on file in my didFinishLaunchingWithOptions, then I assume the happy path and open a "logged in user session" asynchronously using the access token I found on file at time of app open. If the access token I have on file to open the session with is legit, then no UX is displayed. If the access token I have on file is an illegitimate access token (server says it's too old, for example), then my open session method in my app delegate, upon finding this out, will display the proper modal login flow.
Since this openSession method executes asynchronously, you might be wondering how your root view controller, which needs a logged in user, is going to function in the meantime.
The answer is that it should be written as if it does have a logged in user. It should assume. If it ever runs code that can't run or finish executing successfully because it doesn't have a valid access token then that code should trigger the login UI if it's not already presented (i.e. the access token check on app open, by this time, has already presented the modal login UI to the user).
Lastly, this is a translated version of the Facebook SDK login flow. For example, if you use only their SDK you wouldn't ever be interfacing with NSUserDefaults like I suggest. I've translated their flow to a "custom implementation" of logging in to a remote API.