I am building a mobile application using Xamarin.Android. I am also trying to use the Azure Offline Sync. There will be many Activities for various models to be displayed in lists. The question I have is, what is the best method of using the MobileServiceClient? Should I initialize it in the first activity that opens in my application and then pass it to other activities for use? How do I pass that object to other activities? Or is there a way to just initialize it on the first activity and then call it from other activities? Has anyone done this and have advice on the best practice? I have read this SO entry: Passing custom object between Android activities in C# and that seems to be about serializing data to pass it between activities. I don't think I want to pass this as data, I want the full service to be available to all my activities.
Please refer to this. It is about how to create MobileServiceClient in Native Android, but it also can be used in Xamarin.Android.
There is a AzureServiceAdapter class in the link, you can use it to operate the MobileServiceClient class.
About the AzureServiceAdapter:
The MobileServiceClient class should be singleton-pattern.
Initialize the AzureServiceAdapter in your main/first Activity.
Use AzureServiceAdapter.getInstance(); to get the MobileServiceClient's instance in other Activities.
Related
I am able to fetch the history messages for a channel and I need to put the array of those messages into the prebuilt UI MessagesList that they gave me, they mention in their docs that I should override or subclass but how to do that exactly? I am still a beginner with swift, I'm using UIKit not SwiftUI. thanks in advance
To clarify, MessageList is an inherited class of UIViewController, and is used to display a list of stored message objects. The mention of overriding core functionality is discussing using the default MessageListComponentViewModel to display the messages of a particular channel. The docs are explaining that you only need to use the MessageListComponentViewModel to obtain the history messages of a channel, but that you could also add your own overridden functionalities from the base UIViewController if wanted to do so.
For the problem at hand, after consulting with our PubNub engineers, you'll need to populate your local database with data. For example, if you want Messages to appear for a Channel, then you can use either the load(messages:) method if you have Messages already created locally, or thesyncRemoteMessages(_:) method if you want to sync messages from PubNub storage.
I strongly recommend following the Getting Started guide. The guide shows how to create local objects for use with Message List UI in a real chat application, and you can use the Message Input (at the bottom of the UI) to publish messages.
If you would like another example, you can follow PubNub's tutorial on adding iOS Chat Components to an existing application.
I'm making an e commerce app and have all the prices in a Map in firestore. I was looking forward to make a global variable that can be accessed from every part of the app and that updates if there's a change in the database.
What I'm trying to avoid is using StreamBuilder everytime I need to access a price.
I'm been trying to come up with a solution but every way I've found of dealing with firestore is using the StreamBuilder method, and I can't find a way of turning that into a variable.
I know my explanation may have been a little messy. But basically what Im trying to do is " Map price = 'Map in firestore' "
Any ideas? I'm new in flutter, so thanks to everyone in advance!
Yes, you have to use StreamBuilder in everywhere if you want reactive widgets. Because if the data update itself, so your widget has state, because of that you need a StatefulWidget(StreamBuilder is a StatefulWidget).
Imagine you get the variable you want, even so you'll still need a StreamBuilder similars like FutureBuilder or ScopedModelDescendant(if you use ScopedModel) or Provider(if you use provider package) and the list is go on depending on which package you use...
Don't be afraid of using them. If you make rest of the page StatelessWidget, you won't notice any performance issue probably.
You can use Inherited Widgets.
Watch this video:
https://www.youtube.com/watch?v=Zbm3hjPjQMk
You can read the data when your App starts using BLoC to separate the data from the UI. It is explained here:
https://www.youtube.com/watch?v=fahC3ky_zW0
My app will be used by one user. However, there will be a lot of user related info. So i have a class called User.h/.m and #property many fields. One one instance will be made of this class since only one user will be using the phone.
My question is,
1.should i adopt a singleton design pattern for this class? I don't want to continuously instantiate this class again and again thru out different view controllers.
I'm saving all info about this class using core data. Having said that, does this compel one to use singleton more?
is singleton design pattern the way to go? or should it be using external json file or plist?
Thank you
Like #iOS Weblineindia said Singleton will do the job just fine. But if you think in different direction, maybe not. Did you consider that your User obj can have more than one Google (lets assume) accounts? How your app wil interact and deal with such social accounts?
Here is the real use case scenario - I have one account when I'm at work (mail, services, drive etc.) and separate one when I'm out of the office. I want them to stay separate. I'm in such position myself now.
Maybe if you hare some more information about your User class logic it'll be easy to answer.
My question is mostly related to an architectural or design pattern for hierarchical models in Objective C. For background my app is relatively simple. In general it talks to a web service to retrieve and display things a user can follow. When someone follows something, the thing they are following is conceptually stored for access later by posting to the web service.
I would like advice on where the logic should go to manage the interaction between the web service and the group of things a user follows.
For example, is it appropriate to create a model object like MyStuffModel with an array property named followedThings that holds references to AThingModel objects? And if so, would the logic for refreshing from the web service, etc be written and executed in the model?
Potential code example
#interface MyStuffModel : NSObject
#property (nonatomic, strong) NSArray *followedThings;
- (void)refreshAllFollowedThingsFromWebService;
#end
#implementation MyStuffModel
- (void)refreshAllFollowedThingsFromWebService
{
//call my API client (built on AFNetworking), get back a response
//populate followedThings, notify a view controller, etc
}
#end
Or, should I not have a MyStuffModel object and manage the calls to my web service by calling my API client directly from a view controller?
In your experience, which approach is desired? Or is there another way?
I would do all of the networking from within the model. Here's an outline of how all the pieces fit together
the controller tells the model which items to follow
the model forwards that information to the server
when the server has new information, it uses APNS to notify the model
the model requests the new information from the server
after the data transfer is complete, the model uses NSNotificationCenter to inform the controller that new information is available
the controller reads the information from the model
the controller updates the view with the new information
Using Apple's Push Notification Service (APNS) allows your server to notify your app when new data is available. This helps reduce network traffic since your app doesn't have to constantly poll the server to determine when new data is available. If you aren't familiar with APNS, there's one very important feature of the service that you need to be aware of (since it seems to be a point of confusion for many new users). The service only guarantees delivery of the last message sent. So, for example, if the server gets 10 new items for a particular device, and sends 10 notifications to the device while the device is either off or in a tunnel, then the service is only guaranteed to deliver the 10th message. The point is that you can't use APNS to send any data from the server to the device, since some messages may be lost. You should only use APNS to notify the device that data is available.
I always create model classes (and interfaces, no idea if thats applicable in ObjectiveC).
The model is in many cases a view of the database backend.
Your model class should hide the database access and provide a simple interface, for example using a addNewFollower method. This method should then (optionally do sanity checks) and persist this to the database backend.
This approach allows you to easily replace your database integration without touching the service layer at all. For example using an in-memory mock database for testing.
I always create simple "dumb" objects for models, as they model the data, nothing more. If you're doing networking/api calls, I'd create a separate set of classes that deal strictly with API calls and utilize your models as the interchange data. Mixing data and functionality is always fishy to me.
Writing a clean, reusable, testable, and reliable API client, that can handle errors, parallel/serial calls, logging etc, requires quite a bit of code that really should be separated from your other application tiers. Data is just data, keep it clean, keep it simple.
The other thing is that some endpoints don't always return data exactly as it is defined in that 1 model where you are shoe-horning all of your code.
I wouldn't put it in the controllers either, I personally always create a different set of classes that can be used specifically for API calls, which also throw their own exceptions, handle serialization/de-serialization etc.
I need to share some sensitive data among activities.
I have two EditText which are basically username and password
I am consuming a webservice which on the base of provided username and password return some user info (DataType:String). Like userid,useremail etc.. which is basically in CSV format
I need these piece of information throughout my application.But i can't figure out which is the better way.
-- One way i could found out so far is to use sqlite with MonoAndroid
-- Other way i found out is using Application class
I just started to learn android today , but i want to know if there are some other ways to share data ?
As you mentioned, a global Application class and the database are two good ways to share application-wide data. One thing to be careful with is that your Application class could be recycled when the app is in the background, so you would lose any data that hasn't been persisted to something more permanent.
In addition to the database, you can also persist data down to the filesystem as well. This recipe from Xamarin has an example of writing directly to a file. Most of the classes you'll need to do file access are found in the System.IO namespace. Mono for Android also supports isolated storage, which provides a higher level API for reading and writing files.
If you simply need to pass data directly between activities, you can do so by adding it as an extra to the intent. This recipe explains how to do that.
If you want to wrap up access to a particular resource in a more managed fashion that can be accessed by either other parts of your application or even external applications, you can look into implementing a content provider. Android itself provides several built-in content providers for resources like contacts and media, if you need an example of what it's like to use one. This recipe explains how to read from the contacts provider.