I am looking a bit under the AspNetCore/Identity/UserManager and SignInManager still wondering if I should use this implementation or should I just copy and adapt to whatever i need.
Looking over the SignInManager I noticed something really wierd, and perhaps somebody could help clarify this for me.
The userManager class has the ClaimTypes configurable and the default value for the userId is ClaimTypes.NameIdentifier.
The SignInManager does not use the same approach.
Is there a reason why they are using ClaimTypes.Name in SignInManager to check for the userId?
Is the implementation of the method in the SignInManager correct? What happens if I decide to change the type of the claim for the name and userid in the UserManager options
Maybe I don't understand but I hope that somebody can explain it to me.
Thanks
Related
In Spring about AOP/AspectJ exists the MethodInterceptor interface. It is used internally to decide if an #Aspect class must be called or not - really an advice method - according with a pointcut.
About its implementations exists (see the former link):
AspectJAfterAdvice
AspectJAfterThrowingAdvice
AspectJAroundAdvice
Question
What is the reason or Why does not exist the AspectJBeforeAdvice class?
This is not meant to be a conclusive answer, because I cannot speak for the Spring AOP team or speculate more than just a little bit about their design goals and motives. Insofar, this question is not a good fit for Stack Overflow, because it does not present a programming problem to be solved by a correct answer.
Anyway, actually it seems that the AOP Alliance's MethodInterceptor interface is not implemented for before advice types. Either it is not necessary or was an oversight. I think, however, that Spring AOP mostly revolves around the Advice interface and, where necessary, its subinterfaces BeforeAdvice and AfterAdvice. Moreover, all concrete advice types extend AbstractAspectJAdvice. This is a screenshot from my IDE:
Please note on the bottom of the picture, that MethodInterceptor itself extends Interceptor, which again intercepts Advice. So, Advice is the common denominator for all advice types, no matter if they are also MethodInterceptors or not.
I'm aware it's a complex question that cannot have a definite answer without posting a few hundreds of lines of code, which is why I'm looking for help through general ideas and pointers.
I have a Room #Query returning a RxJava3 Flowable<List<...>> which I subscribe to on RxJava thread Schedulers.io(), and observe from an activity-scoped ViewModel on RxJava thread AndroidSchedulers.mainThread(). The data is then stored in my ViewModel as LiveData, which plays better than RxJava when it comes to handle Android components' lifecycle.
The idea is to have a clean and immediate data update pattern, not to have to handle disposal and re-subscription separately on each activity or fragment lifecycle event such as onPaused and onResumed, and being updated in the background even when my activity is hidden in order to avoid that awful refresh lag when returning to my activity. I was pretty amazed at that design pattern. I still am, but I'm beginning to have doubts.
When starting another activity with the same design pattern, I do change a value and immediately get an updated List<...> from the other ViewModel. Different Activity, different ViewModel, same design, same database table. When returning to the first Activity, I find that the new data does never get updated: Room did not emit any update even though the data set has changed. I have to dispose and subscribe again in order to see the new data.
So my question is: any pointer on where the source of my problem might be?! Is there something rotten in the core of this design pattern? Something I misunderstood about all those things are supposed to work together? Is it just a mistake of mine due to some threading issue? Or should I fill a bug report for Room?
I tried to observe another non-Room RxJava3 observable from the ViewModel of my first Activity, and it does get updates when its data set is updated.
By the way, I also use Hilt in order to inject eveything as #Singleton.
Thank you for your time :-)
After a week of headaches, I have finally stumbled upon a solution, which happens to be clean and elegant.
The issue was RxJava, which, I just learnt, is not supposed to seamlessly handle multiple subscriptions to the same Observable. The solution is supposedly to make use of the publish(), connect(), refcount() operators, or better use the shortcut share(). I tried every way I could think of, without success (it actually made it worse). I also tried to subscribe() to the Room Flowable from my repository and proxy it through a BehaviorSubject.
There was this weird org.reactivestreams.Publisher in Room's documentation, whose added value I wouldn't know, and whose origin wasn't even my familiar io.reactivex.rxjava3. It turns out it that was the solution. Edit: It turns out Publisher is an interface that Flowable happens to implement.
build.gradle
implementation 'android.arch.lifecycle:reactivestreams:+'
Dao.java
#Query("...")
Flowable<List<...>> getFlowable();
ViewModel.java
public liveData;
#Inject
public ViewModel(#NonNull RoomDatabase roomDatabase) {
liveData = LiveDataReactiveStreams.fromPublisher(roomDatabase.dao().getFlowable());
}
It seems too easy to be true, but as far as I can see it seems to work perfectly better this way.
Edit:
It turns out the root of this issue was a slight little bit more vicious than I thought. I assumed #InstallIn(SingletonComponent.class) in my dependency injection #Module was enough, but apparently a #Singleton annotation on each #Provides method is also required.
#Module
#InstallIn(SingletonComponent.class)
public abstract class DependencyInjection
{
#Provides
#NonNull
#Singleton // do not omit this
public static DataDao provideDataDao(#NonNull RoomDatabase roomDatabase) {
return roomDatabase.dataDao();
}
#Provides
#NonNull
#Singleton // do not omit this
public static RoomDatabase provideRoomDatabase(#ApplicationContext Context applicationContext) {
return
BuildConfig.DEBUG ?
Room.databaseBuilder(applicationContext, RoomDatabase.class, "playground.db").fallbackToDestructiveMigration().build() :
Room.databaseBuilder(applicationContext, RoomDatabase.class, "playground.db").build() ;
}
}
Hey guys,
I'm not having a problem, I was just wondering what's the best way of implementing isSomthing in OOP paradigm?
Take this example: we want to know if the user was temporarily (like 10 minutes) banned. Here are the two options:
Implementing isTempBanned() method in the User class. Then whenever we want to check if user is banned, we just call this method. no change to the other parts of the code is required.
Adding a isTempBanned property to the User class. Then whenever the state of user's ban changes, we update this property accordingly. Then when we need to know, we just use this property.
Can you explain Pros and Cons of each way? from these standpoints:
performance
code maintainability
clean code
readability
etc...
Keep in mind that there is no better way. I'm just asking to know when should I use the first method and when to use the second one.
Ultimately you have to use both of them!
based on Encapsulation principle , think of your example as a getter/setter scenario, to keep bugs as low as possible,
getter is User.isBanned method, setter is User.banUser method.
class User{
banned_until : Date = null
isBanned(){
if(this.banned_until){
return this.banned_until.valueOf() > new Date().valueOf();
}
return false;
}
banUser(){
this.banned_until = new Date() ///any date in future ....
}
}
isSomthing is usually used for boolean. no matter what data type you use. all differences are method and property differences.
I suggest you read this:
Properties vs Methods
I’m going through preparation for a professional assessment and at the moment I have a question that I can’t give a complete answer to, as I am new to Apex.
Question: Describe the features of static methods. What methods(necessarily) must be static?
There are no problems with the first part, but I would like to find an exhaustive answer somewhere in the second part. Annotations # Future for example, etc.
static methods need to be used when you don't need an instance of a class or if the method needs to be exposed to other callers. Examples of this are lwc/aura/visualforce remoting methods.
See these links for examples of why static is necessary
https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_apex.htm
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.apex
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_RemoteAction.htm
What is the default advice kind when using <aop:advisor>? Is it around or something else? I did not find much information in docs. Any link to more information? Thanks.
Well, as the documentation says here:
The advice itself is represented by a bean, and must implement one of the advice interfaces described in Advice types in Spring.
Thus, it is your own choice which type of advice you want to implement in your advisor. It can be any of
around,
before,
after returning,
throws,
introduction.