Implementing a ViewModel for entire the application - android-studio

I want to build a viewModel for entire the application to send and receive data between multiple fragments and activities. so, how can I do that

Do not implement ViewModel scoped to the application
From Wikipedia article:
The viewmodel of MVVM is a value converter, meaning the viewmodel is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented. In this respect, the viewmodel is more model than view, and handles most if not all of the view's display logic. The viewmodel may implement a mediator pattern, organizing access to the back-end logic around the set of use cases supported by the view.
From ViewModel class documentation:
ViewModel is a class that is responsible for preparing and managing the data for an Activity or a Fragment. It also handles the communication of the Activity / Fragment with the rest of the application (e.g. calling the business logic classes).
A ViewModel is always created in association with a scope (a fragment or an activity) and will be retained as long as the scope is alive.
ViewModel's only responsibility is to manage the data for the UI.
It's clearly defined that ViewModel is a binder between View and Model and nothing more. Currently only Activity, Fragment and their subclasses implement ViewModelStoreOwner interface allowing ViewModel be scoped to them.
Also Application scoped ViewModel violate the important SOLID principle - Interface segregation (ISP). It states following:
ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
How to send and receive data between activities and fragments?
Some ways to communicate easier than application ViewModel:
Between activities via Intents
Between fragments via Bundle, via Navigation Component with Safe Args and via ViewModel
Between activity and fragment via Fragment.setArguments()

Related

The Blazor Way to "share" an object among components, routes, pages, etc

My application will have the user open a file that will be read by the application, and that file will contain database information that will be stored into an object.
The way I see a Blazor app now is that MainLayout.razor is the component that renders my full page: the navbar and the #Body. I would like the file name I grab from the open dialog box to be passed to my project where I then create my object and fill it with the file information.
I got working where I created the object in one of the blazor component modules, only to realize that I would need to do this for all my modules, that is read and parse my database into an object everytime the user clicks a new tab to load a new component. I would like this reading and parsing of the database to be done once, stored in my object and have that object be available to all potential blazor components in my project.
Where should I define the instance of my object and how should I make that object seen and even be updated by all other components? Is this even possible? Am I passing this object as a parameter, is it part of my routing. I'm not sure how to go about this.
Three ways:
State Class
Create a class with the properties you want to share. Make the class observable. Don't use property setters to change the values, use a method, that not only updates the state it notifies listeners of the change.
This class is provided for injection in program.cs
Cascading Value
Same as the state class but presented as a cascading value instead of injection. This has the added advantage of being able to scope the listeners of the value within the html hierarchy.
Local or Session Storage
Use JSInteropt to save values to sessions/local storage. The relevant components need to listen for updates and read the storage.
As you have not provided any code or shown any attempt I only listed a broad outline of ways achieve this. In my opinion for your scenario, option 1 is the best choice.
The link you suggested has no way of notifying listeners. The components will not react to changes that occur after initialising.

Apply IHasRequestFilter to Plugin registered service dynamically

I have a set of Services that I want to use in various ServiceStack projects (okay, two) so I have created a ServiceStack Plugin that registers them.
However I want to allow users to determine their own method of securing access to these services.
Currently I have an IHasRequestFilter in one my projects that can determine which services a user should be able to access. I do not want a reference to this in the Plugin project, so I want to add this dynamically after the fact.
I want to somehow get a reference to the Service Definition in AppHost to add this IHasRequestFilter to the pipeline for a specific set of services.
Ideally I should be able to do something like this:
new CustomPlugin(new CustomPluginParams {
RestrictTo = CustomRestrictions,
RequestFilters = [],
ResponseFilters = []
});
This should use those properties to configure their services without having a previous typed reference.
Edit:
Investigating further it appears that the IHasRequestFilter and IHasResponseFilters are only parsed once, in the ServiceExec<TService> class. I could get round this by creating my Services with a Proxy which adds the attribute I require to the MemberInfo of the operations, however I don't regard that as a clean approach.
Does anyone have recommendation?
In ServiceStack all configuration should happen within AppHost's Configure() method and remain immutable thereafter.
Lifecycle Events
To help with LifeCycle events there are IPreInitPlugin and IPostInitPlugin Plugin Interfaces which your Plugins can implement so they will get called back before and after all plugins are registered.
There's also an IAppHost.AfterInitCallbacks plugins can use to get called back after the entire AppHost has finished initialiazing.
Typed Request/Response Filters
Attributes are typically statically defined on Services, to dynamically add logic that apply to specific Request/Responses you can use a typed Request/Response filter.
The nice thing about ServiceStack Filters is that they share the same API (IRequest, IResponse, object) which makes them easily composable, e.g:
RegisterTypedRequestFilter<CustomRequest>(new RequestAttributeFilter().Execute);
Dynamically adding Attribute filters
As all ServiceStack libraries use ServiceStack.Text's Reflection API's you're able to extend ServiceStack's attribute-based code-first API dynamically by adding attributes to types or properties at runtime, e.g:
typeof(CustomRequest)
.AddAttributes(new RuntimeAttributeRequestFilter());
This can be done for most of ServiceStack's code-first API's inc. Request/Response Filters.
Route attributes and Action Filters
There is sometimes an issue for Services Route attributes and Action filters that already pre-configured and autowired before the AppHost's Configure() is called.
One solution is to add them in the AppHost constructor (or by overriding AppHost.OnBeforeInit) so they're added before the Services are configured. Otherwise you can reset the action filter caches by calling the AppHost's ServiceController.ResetServiceExecCachesIfNeeded().

re-using ServiceStack validation in Winforms offline client

We have a working website using ServiceStack as the back end that amounts to a complex data-entry form.
My users have requested an "offline editor" for the forms. To use the offline program, the user will have to connect to the ServiceStack service, create empty instances of the forms, and then I will save the POCOs from the service to disk using ServiceStack's JSON serializer. From there the user can log off the service and edit the POCOs. When they're done, they reconnect to the service, and post/put the edited POCO object.
This all works great. My question involves validation. The validation logic is built into my Service.Interface library, which isn't available offline. The winforms program references only the POCO library and the ServiceStack "common" libraries, which do not look like they include the ServiceStack.Validation namespace.
Is there a way I can rearrange my project so that both the service and the Winforms client can run Validation against the POCOs, so that they can have data validation while offline?
UPDATE:
getting closer, I think - I moved all of the Validation classes into their own project. From my Winforms project, I can now manually set up a validator for a POCO class like this:
ServiceStack.FluentValidation.IValidator<SomePOCO> IValidator;
IValidator = new Tonto.Svc.Validation.SomePOCOValidator();
ServiceStack.FluentValidation.Results.ValidationResult vr =
IValidator.Validate(_rpt);
I can see the validator constructor being set up and the rules being initialized, but the .Validate method doesn't seem to do anything. (object comes back as valid, and breakpoints into custom validator code never get there).
UPDATE #2
I discovered my validator code wasn't running from Winforms because my validators all specify a servicestack ApplyTo Put/Post only (see sample code below). When I remove the entire Ruleset clause, though, then validation happens in my service on GETs - something I never want.
Can anyone think of a way to configure the validator rules to run for POST/PUT only when called from ServiceStack, but to also always run when NOT in servicestack? So close!
public class SomePOCOValidator : AbstractValidator<SomePOCO>
{
public SomePOCO()
{
RuleSet(ApplyTo.Put | ApplyTo.Post, () =>
{
(rules)
});
}
}
If your validation is doing anything interesting, then it probably HAS to be done "online".
Maybe just allow your client to save the POCOs locally until they go back online, at which point you send them up to your server. Any transactions that are okay, get processed normally, and any that fail, get returned for the user to edit (so your client will need some smarts to have a working set of POCOs for editing)...
If you don't want ANY extra stuff on the client, just have the transactions that fail to validate get stuffed into a "needs_corrections" table on the server, and then code up a supervisor-sort of screen to manage that table.
The validation framework that ServiceStack uses is named FluentValidation. There is no WinForms support in it. Jeremy Skinner the creator of FluentValidation answerd a question about this back in 2010 on his forum here.
Personally I don't use FV with WinForms - the vast majority of my projects are web-based with the occasional WPF project.
However, if I was going to do this then I probably wouldn't validate the controls directly, but instead use a ViewModel which is bound to the controls. I'd use a fairly strict convention where the names of the controls would match the names of the properties that they're bound to. Then, after validation completes I'd walk the control hierarchy to find the control with the name that matches the property that failed validation (I'm not sure how you'd do this in WinForms, but in WPF I'd use LogicalTreeHelper.FindLogicalNode) and then use the ErrorProvider to set the appropriate error.
Jeremy
I was able to work out a solution that allowed me to use ServiceStack validation libraries on both a ServiceStack client and an offline client. Here are the details.
Move all AbstractValidators to their own project: Proj.Svc.Validation.
get rid of all RuleSets in your AbstractValidators.
Reference Proj.Svc.Validation from Proj.Svc.Interface and Proj.OfflineWinformsClient projects.
Turn OFF the ValidationFeature() plugin in your service. All validation will have to be done manually. This means no iOC injected validators in your service classes.
When it's time to validate, either from your service or the offline client, manually declare the validator and use it like this.
IValidator validator = new
Tonto.Svc.Validation.SomePOCOValidator();
ServiceStack.FluentValidation.Results.ValidationResult vr =
validator.Validate(poco);
if (!vr.IsValid)
(throw exception or notify user somehow);

Creating Database class Library using NHibernate

I am writing an Class Library as DataModel. DataModel capable of handling all the Database related task. I am using NHibernate and Fluent NHibernate for the same.
Now the question arises are as follows :
Should we expose the Entity (POCO Class).
Is it good to have a Entity with internal protected property and property exposed as a interface.
Entity created for mapping can be a Model for WPF MVVM.
Or should we directly bind entity ?.
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
Is it right to throw Exception occurring in an API or should I return null?.
Is it good keep logging in the Library ?.
Should we expose the Entity (POCO Class).
Yes, Creating wrapper class makes more effort.
Is it good to have a Entity with internal protected property and property exposed as a interface.
Yes, Setter and non-exposed properties are control.
Entity created for mapping can be a Model for WPF MVVM.
For primitive type can be, but reference can be exposed by interface.
Or should we directly bind entity ?.
If Model is created rather directly use of POCO object. It is much more flexible for refresh cases. User can not change property of POCO object if cancel operation is there.
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
IEnumerable is used to exposed collection by interface.
Is it right to throw Exception occurring in an API or should I return null?.
Exception is much more better to make know to user about error. but wrap the exception in user readable rather returning NHibernate exception.
Is it good keep logging in the Library
Logging is very good feature to know about issue.
Should we expose the Entity (POCO Class).
yes, otherwise whats the use of the entities when nobody uses
Is it good to have a Entity with internal protected property and property exposed as a interface.
It depends! internal protected properties are no problem when using an ORM but i prefere to reduce internal stuff to a minimum because i like objects maintaining their own state. interfaces are fine
Entity created for mapping can be a Model for WPF MVVM.
of course. No need to duplicate them another time. That's what persistence ignorance is for
Or should we directly bind entity ?
More ofthen than not, the UI requirements are very different than persistence/businessrules so there will be specialised ViewModels for UseCases/Views. However simple Dataholders like Order class thrown into Lists can be bound directly (e.g. using a DatabindingFactory to make them implement INPC)
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
Lists are just in memory container. The user still has to go through the API to Save/Update state.
Is it right to throw Exception occurring in an API or should I return null
if collections are returned then empty collections are far better than null.
Exceptions however should bubble up preferably wrapped in own handable Exceptions. Implement NHibernate.Exceptions.ISQLExceptionConverter (e.g. like NHibernate.Test.ExceptionsTest.MSSQLExceptionConverterExample) and configure it with e.g.
config.DataBaseIntegration(db => db.ExceptionConverter<MyExceptionConverter>())
Is it good keep logging in the Library
absolutly. Logging enables debugging deployed applications. (Fluent)NHibernate already has lot's of logging built in use it if possible.

SharePoint webpart connections

Is it possible to have a bi-directional web part connection? I am aware that a web part can be both a provider and a consumer but it seems only one connection is allowed between two web parts.
What I am trying to accomplish is a bi-directional connection where a field in web part A can update web Part B and a field in B can update web part A.
You can do this in several ways.
The main things to understand are:
You're in complete control of the interface the web parts share
By default only the consumer knows anything about the other web part
Here is then a couple of ways to implement what you describe:
Option 1: Pull/Push:
You can make your interface such that the consumer can pull the information it needs by either calling function or getting property values
And the consumer also pushes the information the other webpart might need by calling functions or setting property values.
Option 2: Consumer announcing
Here you define your interface (and way of using it) such that when a consumer get's a connection it make a call back through the interface to give the producer a reference to the consumer. This reference can then implement the same or another interface any way out want.
Now both the consumer and the producer has a reference to another web part where they can get the information they need.

Resources