Two view controllers with similar functionality VIPER - ios

I'm currently trying to implement VIPER-architecture in my project, and there is some questions I encountered with.
I have two modules in my app, that have some similar functionality (they both have imagePicker and ability to upload media to server, that implemented absolutely the same for both screens).
My question is how could I reuse this similar functionality in both modules? Trouble is that my imagePicker has many methods declared in Interactor that handle different events while selecting and uploading image (such as didUploadMediaFile(), didFailToUploadMediaFile(), uploadMediaFile() and so on).
Should I create third module with this functionality and then somehow subclass my other modules from it? Or maybe there is a better way of doing it?


The only similar components/methods I'd use are Data Managers, which can be shared between as many Interactors are you want, and yet being 100% compliant with VIPER architecture.
So, a DataManager called, for example, MediaApiDataManager() would be responsible for the implementation of the core code to UploadMediaFile() etc
I suggest you read this post for more great tips on VIPER: https://www.ckl.io/blog/best-practices-viper-architecture/


I think you need create abstract class and implement inside imagePicker logic. Declare interface (protocol) for it class with didUploadMediaFile(), didFailToUploadMediaFile(), uploadMediaFile() methods, implement this methods in class and inject to your VIPER modules


For the two modules try to abstract the similarities and try to build a Class of it. If both classes differs on the data type use Generics, also you can use Protocols, so declare the common methods of the two modules in one protocol and implement each one of them as an extension.
Maybe this tutorial helps. https://medium.com/#richiemon/protocol-extension-dispatching-6d5229f1338e

Related

Is it a good idea to write the whole code in the ViewController?

I've developed an App with Swift. Now I want to know if it's a good idea to write whole code in the ViewController or is it better to create more classes?
So can you recommend writing everything in the ViewController from your own experience?
The App I created is a camera and I think that it's inconvinient to have more classes, isn't it?

I think you should just follow the MVC (Model View Controller) pattern since that's how UIKit is written.
According to the MVC design pattern, the controller contains UI logic. It responds to changes in the model and the views' events (e.g. tapping). This means that you should not draw your custom views in the controller. Do that in a separate view class. Also, create model classes where neccesary. For example, a Filter class that represents a filter that you can add to the camera.
Remember that the model should be UI independent!

There are some good design pattern for your project like MVC, MVVM and other also. Can divide your code in the other part like Singleton class and Model class help you manage your code better way separate your applications business logic and any other reusable code or extensions.
Here i am providing you the good one VIPER architecture.

Not depends on iOS and ViewController, in any case write all in one class is bad practice. Follow more about SOLID principles and other software design rules and suggestions.

Best practices for ServiceCollection extension methods?

I'm trying to figure out how best to implement extension methods that register services when users of my library may want to override some of the default implementations of various interfaces. It seems like there are 2 ways of doing things.
The first way is to use services.TryAdd inside the extension method, which would enable you to register the override implementation by using services.Add before calling the main extension method so that your implementation gets there first. This works because .TryAdd won't add if there is already something registered for the interface.
If the extension method uses plain old services.Add instead of .TryAdd then you can still override the implementation but now you have to register your implementation after calling the main extension method that adds the default implementation.
To me it seems the first approach is the better one. If you call services.Add more than once with a different implementation of the interface then they both do get registered and you could actually take a dependency on an IEnumerable of the interface to get all of them. But if you really only need one implementation in the app then it seems better not to have any extra implementations in the collection. Obviously if the app does use multiple implementations of the interface then you would want to add all the ones you need.
I wonder if there is a consensus about this or a recommendation or is it just up to individual taste.

Objective C: is Posing available for ios?

I am trying to implement posing for one ios project.
The scenario:
Defining class of controller at run time
I realise that poseAsClass or class_poseAs is not available for ios
& also deprecated for macOX.
will be grateful to any directions to implement posing in ios. Thanks

The whole pose / swizzle approach is really useful if you want to tamper with the OS / private SDK supplied classes - but you generally shouldn't be doing that and it's not a good idea to use it as a standard approach in your own code.
The scenario: Defining class of controller at run time
You would usually do this by using an abstract superclass / interface / #protocol to define the interface that your potential controllers need to implement and then switching them in and out at runtime.
In your case it seems that you would have one controller which acts as a proxy for the true controller. You also don't technically need an #protocol because UITableViewController is effectively your abstract superclass, but it would be best for your proxy to be a UITableViewController and own the view and for your other controllers to be NSObject subclasses and simply conform to the UITableView DataSource/Delegate protocols.

You should look into Method Swizzling. It helps you change the functions/function bodies at run time.
There is a great tutorial here.

Defining class of controller at run time [duplicate]

I am trying to implement posing for one ios project.
The scenario:
Defining class of controller at run time
I realise that poseAsClass or class_poseAs is not available for ios
& also deprecated for macOX.
will be grateful to any directions to implement posing in ios. Thanks

The whole pose / swizzle approach is really useful if you want to tamper with the OS / private SDK supplied classes - but you generally shouldn't be doing that and it's not a good idea to use it as a standard approach in your own code.
The scenario: Defining class of controller at run time
You would usually do this by using an abstract superclass / interface / #protocol to define the interface that your potential controllers need to implement and then switching them in and out at runtime.
In your case it seems that you would have one controller which acts as a proxy for the true controller. You also don't technically need an #protocol because UITableViewController is effectively your abstract superclass, but it would be best for your proxy to be a UITableViewController and own the view and for your other controllers to be NSObject subclasses and simply conform to the UITableView DataSource/Delegate protocols.

You should look into Method Swizzling. It helps you change the functions/function bodies at run time.
There is a great tutorial here.

Should Class Helpers be used in developing new code?

Delphi 8 introduced Class Helpers for the purposes of mapping the VCL/RTL to the .NET object hierarchy. They allow injecting methods into an existing class without overriding the the class or modifying the original. Later versions of Delphi found class helpers improved and they were ported to Win32.
In the help it says "they should not be viewed as a design tool to be used when developing new code."
Class Helpers violate traditional OOP, but I don't think that makes them a bad thing. Is this warning warranted?
Should class helpers be used when developing new code?
Do you use them when developing new code?
Why or why not?
Per Malcolm's comments: New code means daily application development, where you have some 3rd party libraries, some existing code, and then code you are writing.

Depends what you mean by "new code".
They aren't really relevant for classes you are newly developing, so in that case, no, they probably shouldn't be used.
But even in a brand new project, you may still need to modify an existing class that you can't change in other ways (vcl class, third-party class, etc). In this case, sure, I'd say go ahead.
They're not evil in and of themselves. Like most other things, you just need to understand how they work and use them in an appropriate context.

Before embracing class helpers as a new tool for fancy code, I think you have to understand the limitations is includes. There is only possible to provide one class helper for one class. So what will happen if you provide class helpers for your classes, and your classes derives from a common class that some other have provided a class helper for?
CodeGear introduces class helpers as 'a hack' to prevent breaking things, not as a cool design feature. When you design code, design it without class helpers. I know you can. When dealing with existing code that you can control, use refactoring. When there is no other way, reach for class helpers.
Thats my opinion any way...

Microsoft based LINQ heavily around their Extension Methods. In that light you should use Class Helpers in new code if that improves your code. See What are good uses for class helpers? for some good uses.

I use them a lot. I use Remote Objects and the objects there are created by the RO engine so you cannot add to them without descending from them and then other bits of messing around. Class Helpers mean I can treat them like any other object. and while a class can only have one helper, you can descend helper classes so you get the inherited behaviour.

Sorry, can't help but be Captain Obvious for a moment: If the internal Delphi people themselves state "they should not be viewed as a design tool to be used when developing new code" then by definition they shouldn't be used. They are there for extending the VCL for their own purposes only. Who else is going to give you a better reason than the people that wrote it?

I agree with Vegar in this: class helpers as a emergency tool. When you know they are the only way to get things done in the time provided. Later, if there's time to it, remove them.
I one time forgot a parametrization thing, and if class helpers didn't exist in Delphi 2006 it would cost A ENORMOUS LOT OF TIME..... With class helpers, it took 6 hours to make thigs work right. BUT, it was an emergency situation - class helpers are an obscure language feature and it create difficulties to new developers to follow the flow of the program.

Maybe a good aproach you can use is (as I use it):
Always give preference to inheritance over class helpers, use them only when inheritance is not an option.
Give preference to Class helpers over bare global methods.
If you're going to need the extendend functionality in more than a Unit, try something else (like class wrappers).
.Net Extensions methods are way too similar and where created and supported for the exactly same reason: Make an Extention of the base classes (rather than an upgrade wich in Delphi.Net was not an option in order to try to make Delphi native code kind of "compatible" with .Net code - IMHO this was too ambitious)
Anyway, Delphi Class helpers are still quite a tool in some situations.

These sound like C# extension methods. I would say that while extension methods like these are useful when you don't have the ability to modify a class that you need to extend with functionality, they are a poor way to design your own code. When designing your own code, you'd like all the functionality to be located in the same code file as much as possible rather than spread across different classes. I'd say use them for what they were intended for -- basically as decorators to add new functionality to closed classes -- and don't use them in designing your own code.

I find myself using them more and more as a design construct.
Situations in which I use them :
In a client/server setup, I extend shared base-classes with class helpers to provide server- or client-only functionality.
To complement VCL/RTL classes (and other third party code) with handy tooling functions.
To work around differences when classes don't share the same inheritance tree (using helpers makes it possible to have have generic Count and Items properties, for example).
In fact, I wish Delphi would accept multiple helpers for the same base class - I've even filed a request for this if I'm remembering correctly.

I found this article very interesting. It deals with C++ but the main ideas are language independent. The main gist is that global routines are sometimes preferrable to methods even in an OOP environment. From this view point, there's less need for class helpers.

Resources