To start, let me say that I have read several questions here about SingleInstance, but still cannot find a direct answer that helps me. That said, I apologize if I missed anything.
Here's my question:
I am building a Xamarin Forms app for iOS and Android. I have a single AppInitializer class in a PCL where I register all of my interface dependencies using Autofac. I then assign the Container from the builder as a static property on the app class. The problem I encounter is that while I'm registering everything with .SingleInstance(), I'm not actually getting a single instance.
Init Logic Example:
var builder = new ContainerBuilder();
builder.RegisterType<ErrorHandler>().SingleInstance().As<IErrorHandler>();
…
builder.RegisterType<MemberViewModel>().SingleInstance().As<IMemberViewModel>();
…
AppContainer.Current = builder.Build();
I am letting Autofac handle resolving interfaces in my constructors. For example:
public MemberViewModel(ISettingsViewModel settings, IErrorHandler errorHandler, …) : base(settings, errorHandler){…}
I then use said model on a page as below:
Example page usage:
public ProfilePage()
{
InitializeComponent();
var displayModel = Model.CurrentMember;
…
}
…
**public IMemberViewModel Model =>
AppContainer.Current.Resolve<IMemberViewModel>();**
In this example I set Model.CurrentMember's properties immediately before arriving on this page. I've set breakpoints and know for a fact this is happening. However, when I resolve the instance of the model, the properties on CurrentMember are null.
Am I doing something wrong here or have I encountered a bug?
-Edit-
Made it clear that I'm using Autofac.
-Edit 2-
Adding more detail.
My implementation of the IMemberViewModel class has various properties on it, including an observable object called current member. It is declared as below:
public class MemberViewModel : ViewModelBase, IMemberViewModel
{
…
(see constructor above)
…
public MemberDisplay CurrentMember =>
m_CurrentMember ?? (m_CurrentMember = new MemberDisplay())
On the implementation of IMemberViewModel I have a method that sets the various properties on CurrentMember.
The order of operations is this:
The end user taps an image for a member. This fires a command on the (theoretically) singleton instance of the IMemberViewModel implementation. This command executes an async task that awaits an async call to the API to load the data for that member. After that data is loaded and the properties set on CurrentMember, the app navigates to the profile screen. The profile screen resolves IMemberViewModel (per above).
Expected Behavior:
The properties on CurrentMember from the resolved instance of IMemberViewModel are set to the values that have just been set from the load data method. This expectation arises from assuming that there is a single instance of IMemberViewModel.
Actual Behavior:
The CurrentMember's properties are at their default values, i.e. string.Empty, 0, null, etc.
The odd thing here is that this doesn't happen to every model. I have a message model that I am resolving in the same manner on the same screen and it seems to be fine.
This issue turned out to be caused by the way we were going about initializing everything. For posterity's sake, I will give a brief breakdown of what was happening and what I did to prevent it.
Previous App Flow:
App opens & constructor is called. This calls into the initialization routine above.
User logs in.
First instance of IMemberViewModel resolved using static container.
A message pops up asking the user for Push Notifications Permissions
When this happens, the app OnSleep is called (iOS)
After the user selects an answer, OnResume is called.
OnResume calls initialization routine
New container created.
Call to load data happens on old container, new pages reference new container.
Issue arises as described above.
Correction to the flow:
First, from what I can tell the init calls do not need to be made on resume and/or start if made in the app constructor. If the app is "killed" because other apps need the memory space, a fresh version of the app will be created on next launch (see the Android Activity Lifecycle and the iOS App Lifecycle).
Second, because I'm paranoid and because it can't hurt, in the app init routine I am now checking to determine whether the container exists and whether the interface is already registered.
public static void Init(ISetup setup)
{
if (Container != null && IsModelRegistered()) return;
RegisterDependencies(setup);
…
}
private static bool IsModelRegistered()
{
return Container.IsRegistered<IMemberViewModel>();
}
Related
I am using Realm and building a Swift mobile app. I am really struggling to understand why and when Partial realms are created.
Here is my scenario:
a user logs in to the app and is brought to the first view controller.
In the first view controller in view did load, I am executing a query to get the current user, subscribing to the query and adding an observer to let me know when the data is synced:
let currentUserArr = realm.objects(DBUser.self).filter("id == %#", userId)
self.subscription = currentUserArr.subscribe(named: "current user")
self.subscriptionToken = self.subscription.observe(\.state, options: .initial) { state in
switch state {
case .creating:
print("creating")
case .pending:
print("pending")
case .complete:
print("complete")
self.artist = currentUserArr[0]
case .invalidated:
print("invalidated")
case .error(let err):
//seal.reject(err)
print(err)
}
}
This makes sense that if I check Realm Cloud, I have a new partial realm created with path as:
/db/__partial/DyeOy3OR4sNsqMi2OmDQQEzUa8F3/~7f11cf52
However, here is where my confusion starts. I log the user out. I log back in and again the code above executes. My thought would be that Realm would just reuse the partial already created, but instead it creates an entirely new partial.
/db/__partial/DyeOy3OR4sNsqMi2OmDQQEzUa8F3/~8bc7bc49
Is this by design or should I somehow be reusing partials rather than having a new one created every time a query is executed (even if it is executed by the same user)?
I have posted on Realm Forums as well:
https://forums.realm.io/t/realm-platform-realm-path-partial-s/2833
I don't believe I was actually logging the current sync user out. Upon further testing, once I did log out and log back in, the existing partial was re-used. This is a non-issue.
I'm really having problems resolving this.
The 'HandleNewTag' method is in the Droid MainActivity class. It's a non static but complains about the 'MainPage.HandleNFC' method it's calling, so I changed that to static and it didn't error.
The 'MainPage.HandleNFC' method also calls a method which was non static. I changed it to a static void to stop the error. Then inside that method, where it sets some properties of a XAML control, it complains that the control is not static which I am unable to change.
I've searched high and low on the internet to resolve this and although I can find similar errors, none of them refer to a non static control issue.
MainActivity.cs
public void HandleNewTag(object sender, NfcFormsTag e)
{
//MainPage mp = new MainPage();
byte[] bytes = e.Id;
Console.WriteLine(BitConverter.ToString(bytes));
if (BitConverter.IsLittleEndian)
Array.Reverse(bytes);
Console.WriteLine(BitConverter.ToString(bytes));
// Call method to send byte stream across machine boundaries.
// Receive byte stream from beyond machine boundaries.
Console.WriteLine(BitConverter.ToString(bytes));
if (BitConverter.IsLittleEndian)
Array.Reverse(bytes);
Console.WriteLine(BitConverter.ToString(bytes));
int result = BitConverter.ToInt32(bytes, 0);
MainPage.HandleNFC(result.ToString());
}
MainPage.xaml
public static void HandleNFC(string convertedtag)
{
addToReadout(convertedtag);
}
public static void addToReadout(string text)
{
Label label1 = new Label { Text = "Successfully clocked out # " + text, TextColor = Color.Black };
StackLayout sl = new StackLayout();
readOut.Children.Add(label1);
readOut.BackgroundColor = Color.Black;
readOut.Children.Count();
}
Something is wrong here. Why would you be calling your Forms MainPage (living in PCL or Shared Project) from the Xamarin.Android MainActivity? The dependency flow there is backwards. I'm also assuming "MainPage.xaml" is "MainPage.xaml.cs" as you are showing C# code and not XAML.
Either way, it looks like you want to add tags to a control on your MainPage. The HandleNewTag event handler living in MainActivity.cs probably shouldn't work like this because your solution will get complicated when you have to think about the other platforms. Typically you want your calls to triage from your PCL down to the platform specific projects, like what Xamarin.Forms.DependencyService does (basic container/IoC patterns).
I understand that on Android the NFC capabilities would require the Application or Activity Context to perform actions and the NFC readings you receive are coming in through your MainActivity. One way to handle this would be the MessagingCenter built into Xamarin.Forms. It was designed just for this purpose because then you can also send messages through the MessagingCenter from your iOS or UWP projects and everything will work fine. You would have one MessagingCenter subscription that lives in your MainPage.xaml.cs, I typically will use the constructor for that stuff.
Another option would be to create an "AppViewModel" that lives at your top level of your application. I typically make this a static variable in my App class so I can reference it from anywhere by calling App.ViewModel.(whatever). Your challenge will be taking that data and updating your UI. I would do this by just binding controls directly to the sources in that static instance and creating a "Refresh" mechanism that utilizes OnPropertyChanged to update the bindings. This is of course a more complex solution and is really built/designed around what you are trying to do exactly.
I hope this helps!
Disclosure: I work for Xamarin/Microsoft
I'm experiencing a strange issue with WatchOS (but I suppose that this problem is similar with iOS and OSX).
I'm using a singleton to handle a WCSession delegate (The full code is by NatashaTheRobot, I paste here only a portion of her code, the full code is here ).
This class has a startSession function where the singleton is associated as delegate of the session:
func startSession() {
session?.delegate = self
session?.activateSession()
}
and all the delegate functions are defined inside the same class, like session:didReceiveMessage:replyHandler:
I'd like to be able to have the delegate called every time that the Watch app receives a message independently by the current InterfaceController.
I thought that a good place to achieve this goal might be the ExtensionDelegate class:
class ExtensionDelegate: NSObject, WKExtensionDelegate {
let session = WatchSessionManager.sharedManager // THE SINGLETON INSTANCE
func applicationDidFinishLaunching() {
session.startSession()
}
it seems that this code is not working and the delegate function are never called.
Then I decided to go for a less generic way and I started adding the reference to the singleton instance inside all the InterfaceController... but again it doesn't work and delegate methods are never been called.
Then, in my last attempt, I've implemented the session delegate protocol directly inside the InterfaceController code. In that case I receive the messages from the iOS app... it was working correctly (obviously only when the watch app is presenting that specific InterfaceController).
My question are: why implementing a generic singleton object doesn't work? Why I have to implement the delegate directly on the InterfaceController to make it work?
Try moving the startSession call from the ExtensionController's applicationDidFinishLaunching to its init method. The init gets called no matter which context (complication, app, glance, notification, etc) the extension is being loaded for.
I added a new method to the CustVendPaym class called sendersBankCompanyStatementName of type BankCompanyStatementName.
This is the code of said method:
public BankCompanyStatementName sendersBankCompanyStatementName(BankCompanyStatementName _sendersBankCompanyStatementName = sendersBankCompanyStatementName)
{
sendersBankCompanyStatementName = _sendersBankCompanyStatementName;
return sendersBankCompanyStatementName;
}
I added the definition in the classDeclaration method:
BankCompanyStatementName sendersBankCompanyStatementName;
Then in the method vendPaym in the VendOutPaym class, a new instance of VendPaym (which extends CustVendPaym) is created:
vendPaym = new VendPaym();
//A bunch of properties are set then one I created:
vendPaym.sendersBankCompanyStatementName (bankAccountTable.BankCompanyStatementName);
If I break there, I see the assignment with the value I'm expecting working correctly, but then the debugger (watch) never actually shows the new property I added with the value that's supposed to be in it.
Then if I just continue code execution, the AOS server in which I'm developing just crashes :|
Any ideas, am I doing something obviously wrong ?
Thanks.
EDIT: If I rollback my changes (that is deleting the newly added method and removing any references to it) everything works as it was before.
Have you compiled forward the CustVendPaym class?
I want to use a SQLite session to demo a wpf application; the session uses test data that has been previously created and saved to a db3 test file. I am binding the context, using code similar to what I use in normal testing - working code.
The difference here is likely that I am building the session factory and loading the test data on a background thread. To the extent that this is the problem, I am wondering if there is a different context than the "thread-static" one I am using.
I can see that the contextual session is available on the background thread. Code is below. Does anyone have a suggestion?
============
background thread code
the context is bound here, and is available when GetCurrentSession() is called
public SqLiteDataProvider()
{
lock (padlock)
{
...
var session = sessionFactory.OpenSession();
CurrentSessionContext.Bind(session);
var pathToMother = FileHelper.GetFilePathFromDirectoryName("src", #"mother.db3");
var conn = (SQLiteConnection)sessionFactory.GetCurrentSession().Connection;
SQLiteDataLoader.ImportData(conn, pathToMother);
_activitySubjectDao = new ActivitySubjectDao(sessionFactory);
}
=============
after the background work has finished
The same ActivitySubjectDao is asked to find some data and fails when it accesses the field:
protected ISession _session { get { return _sessionFactory.GetCurrentSession(); } }
When the dao is constructed on the background thread the session is available.
==============
update
I managed to get this to work by separating out the task of building the session factory from that of loading the test data file, and holding the factory reference in the calling class (and discovered I wasn't generating the SQLite schema in the process, which didn't help even a little).
This seems like a fairly common thing to want to do (building a session factory and fetching data in the background) in a desktop app, so I am still hoping someone is aware of a more elegant solution.
I guess the current session is a [ThreadStatic] variable and thus not available to the new thread?