I'm Using Uno-Platform with MVVMLight trying to structure my project.
Should I put platform specific code inside ViewModel? or should it mostly be in Utils/Services?
I would recommend placing platform-specific code inside utility classes or services. Placing that code inside ViewModels would make it harder to reuse and potentially make the ViewModel impossible to run tests against.
Ideally, (not mandatory) you'll want to use Interfaces and dependency injection, provide one implementation for each platform you want to support, and try to implement the same interface for all of them. That way, your ViewModel will not have #if PLATFORM_A code.
Side note, remember Uno platform already offers a lot of platform abstractions through the UWP APIs. Like Geolocator, sensors etc.
Related
I read a lot of ViewModel derived from AndroidViewModel, which then requires of course an application reference.
class SomeViewModel(application: Application) : AndroidViewModel(application)
But why would one do this? It hurts me to see application handed over to ViewModel. What would be an acceptable use case for this?
If there is any reason to use AndroidViewModel, can one not derive from ViewModel + use dagger2 for the application inject?
Not all codebases are created equal. AndroidViewModel can be a useful tool for incremental refactoring in "legacy" codebases that don't have many abstractions or layering in place (read: Activity/Fragment god objects).
As a bridge from a "legacy" codebase, it makes sense to use it in this situation.
But why would one do this? It hurts me to see application handed over to ViewModel. What would be an acceptable use case for this?
The use case for AndroidViewModel is for accessing the Application. In a "legacy" codebase, it's relatively safe to move "Context/Application-dependent code" out of Activities and Fragments without requiring a risky refactor. Accessing Application in the view model will be necessary in that scenario.
If there is any reason to use AndroidViewModel, can one not derive from ViewModel + use dagger2 for the application inject?
If you're not injecting anything else, then at best it's a convenient way to get an Application reference without having to type cast or use any DI at all.
If you're injecting other members, be it with a DI framework or ViewModelFactory, it's a matter of preference.
If you're injecting a ViewModel directly into your Activity/Fragment, you're losing the benefits the platform is providing you with. You'll have to manually scope the lifecycle of your VM and manually clear your VM for your UI's lifecycle unless you also mess around with ViewModelStores or whatever other components are involved in retention. At that point, it's a view model by name only.
Because it requires an application reference, it can provide Context which can be useful (e.g: for a system service).
See - AndroidViewModel vs ViewModel
I am a newcomer to C# / .Net / Prism / WPF / DevExpress and started to work on a big project in my company. As I am starting a bit late in the project, a lot of code was already produced and I stumble upon code like this very often:
public class AboutWindowViewModel : BindableBase
{
public AboutWindowViewModel(IUnityContainer container)
{
...
What I find "special" here is the dependence of the view model in the container. In the codebase I am currently looking at, it seems to be the "pattern". Every class gets a dependence in the IUnityContainer and then the dependencies are resolved manually with e.g.
container.ResolveEx<...>(...);
I am used to work with DI frameworks in other languages, so that example was just a non-sense to me because it goes against the definition of a DI framework and the problems it is meant to solve. For example, I tried to make up some code to test one of those view models and it turned out to be a nightmare.
Now, I addressed that concern to the developpers of my company and they answered me the following:
Prism recommendation is to resolve services using containers as they are needed.
Therefore, they resolve them all the time with the IUnityContainer.ResolveEx method.
My question is: is that really the recommended way to build up software with Prism??? If not, do you know where I can find documentation that clearly addresses that point with examples?
is that really the recommended way to build up software with Prism???
Not at all, in it's an anti-pattern.
Prism recommendation is to resolve services using containers as they are needed.
Not really just Prism, but more generally, the recommendation is to let the container resolve the dependencies. Of course, this can be done by calling Resolve manually, but in doing that one defeats all the benefits expected from dependency injection.
Rather, you want to list the dependencies as constructor parameters and let the container fill them. Your code does not need to depend on the container, except for the very entry-point ("resolution root"). The application should only ever contain a single Resolve statement that resolves the first instance.
Here's where Prism comes into play: in your PrismApplication.RegisterTypes and IModule.RegisterTypes, you configure your container. You tell it which type should implement which interface. Later on, when view models are needed, Prism (the ViewModelLocator to be precise) uses the container to resolve the view models, thereby resolving all the dependencies. There's no reason to make any class depend on the container, in fact, Prism doesn't register anything for IContainerRegistry in the first place.
Keep in mind that the container can not only inject singleton services, but also transient instances or factories. And if you need parametrized factories, you can always manually create and register complex factories.
On a side-note, I, personally, would be hesitant to work for a client with a code-base like this, as it's an obvious proof that their developers have no idea what they're doing.
The visual studio project templates for a Service fabric services contains code that can be reused over other multiple projects. For example the ServiceEventSource.cs or ActorEventSource.cs
My programmer instinct wants to move this code to a shared library, so I don't have duplicate code. But maybe this isn't the way to go with microservices, since you want to have small independent services. Introducing a library will make it more dependent. But they are already dependent on the EventSource class.
My solution will be to move some reusable code to a base class in a shared project and inherit that class in my services. Is this the best approach?
I'm guessing all your services are going to be doing lots of different jobs so once you pad out your EventSource classes they'll be completely different from each other except one method which would be service started?
Like with any logging there is many different approaches, one of the main ones I like is using AOP or interceptor proxies using IoC containers, this will keeps your classes clean but allows re-use of the ETW code and a decent amount of logging to be able to debug later down the line.
I moved a lot of duplicate code to my own nuget libraries which is working quiet well. It is a extra dependency, but always better then duplicate code. Now I'm planning to make my one SF templates in visual studio, so I don't have to remove and adjust some files.
I found a nice library (EventSourceProxy) which helps me managing the EventSource code for ETW: https://github.com/jonwagner/EventSourceProxy
In my hunt for various GUI frameworks, I remembered GTK being a fairly mature library for making user interfaces for desktop applications.
And it got me wondering, is it possible to use the Glade interface designer with Scala? Is there perhaps a Scala-optimised framework or library to make the process more painless?
It appears that there exists a GTK+ binding for Java, and from an unofficial source it seems like you can use this in Scala.
This binding contains class Builder with method addFromFile(), so you should be able to create a UI file in Glade, save it, then load it in your Scala project, and use the method getObject() to access the objects defined in Glade.
For more details you can refer to this question and its answers, which deal with Java, but should be very similar to Scala.
As Scala is interoperable with Java, you can use it's bindings. I highly recommend you to first see a scala REPL micro tutorial for Ubuntu then read and understand what is GtkBuilder and how to create Gtk+ interfaces using Glade. Then a proposed process could be:
Create your apps UIs using Glade
Call GtkBuilder in your Scala code to interact with UI parts (send receive data)
Create Scala script file for each UI
Create a separate backend app with REST interface to present app input/ouput as UI state changes
Connect the two apps
By doing so, you'll get a set of bash scripts (written in Scala) each draw a native UI when executed. Whenever the backend is running, it's possible for UI to be used as I/O of backend app.
I am looking for a framework/library that generates most/all of the generic MVP code itself, so that I can then extend that code. In default GWT-Eclipse IDE setup, I have to write every bit of code by hand.
I have seen a few frameworks like Tessell which aim at generating a large part of the boiler plate code...Which framework do you recommend for this purpose, so that I can create new MVP-GWT apps with minimal effort/fuss?
Take a look at Tessell:
Tessell is a GWT application framework
Follows a Model View Presenter architecture
Less boilerplate (10x less LOC than hand-coded MVP)
Features
View generation of the MVP/UiBinder interfaces/implementations that allow for fast, DOM-decoupled unit tests but that suck to code by hand
Rich models to make your application's presenter/business logic more declarative and have less spaghetti/inner class code
Dispatch-style server/client AJAX communication
Stubs for awesome, out-of-the-box tests
Conventions for forms, row tables, and cell tables
I know people who have used mvp4g on some large projects effectively.
I used gwtp in two projects and it worked really well.
It has the concept of nested presenters/views which might come handy if you want to create reusable MVP components.
The GPE (Google Plugin for Eclipse) and Google Window Builder together will generate most of what you need for MVP code using the GWT libraries. You go to New ->Window Builder->GWT UIBindder->MVP->MVP View. The Wizard will generate the uibinder code, a UI interface, a UI implementation, a place, and an activity. It will also use a client factory if you are using one. If you have a client.place and/or a client.activity package(s) it will also put the places and activities in those packages for you.