3 ms·

(…Here comes the wizard of…) Just hide those system specific components behind a factory and make sure all components conform to a polymorphic API/contract. Th

(…Here comes the wizard of…) Just hide those system specific components behind a factory and make sure all components conform to a polymorphic API/contract. The situation described above, abstracted, happens all the time in software. Littering the code with these system specific conditionals is a pain so encapsulate those system specific concerns in objects/components/whatever-you-call-your-lego-blocks and then use a factory to encapsulate which system specific thing you get. The trade off is your code is a little harder to understand, but the benefit is now you can design a common ‘core’ and contain the platform specific details in bundles. That’s ((just)) my two cents!

phkahler 5y ago
>> Just hide those system specific components behind a factory and make sure all components conform to a polymorphic API/contract. But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that. This guy wrote two bits of code for a text input box which is one of the most basic GUI components there is after buttons.
- sovietmudkipz 5y ago
  >> But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that. That's still true for flutter but it all depends on the requirements of the project. In the OP article, the point was to make something that is "native-looking" to Mac OS and Windows OS. This requirement does imply a requirement for different looking and behaving UI. Lose that requirement and then you can get the non-fractured code base back. Perhaps you may reply "the framework should do that translation for you," to which I would respond "maybe you're right." It would be nice as a framework user to offload this type of work to the framework authors. Conversely, from the perspective of the framework authors they get to work on other features if they offload this type of work to the framework users. I suspect the deeper questions for both framework users and authors is "who owns this work?" "what tradeoffs are users willing to make to gain this framework features?" and "what does joint ownership of this requirement look like?" Different framework communities will arrive at different answers. At the end of the day as a pragmatic programmer you just kinda have to hack around the edges to smooth everything out for the end user.
- swman 5y ago
  In my projects when I need independent UI per platform I just extract the logic to a new component that renders the right thing for each platform. That way my views aren’t filled with conditionals the component handles it.
- smasher164 5y ago
  And this is why I think the goal of a cross-platform toolkit is misleading. If your language/library/compiler make it really ergonomic to conditionally target code for a platform, then you get the benefit of keeping your business logic in one place, and the pain only with testing the application. Usually this is not the case, since interfacing with Cocoa is so different from Win32, for example. However, one shouldn't conflate that difficulty with the difficulty of testing an app across platforms.

phkahler 5y ago

>> Just hide those system specific components behind a factory and make sure all components conform to a polymorphic API/contract. But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that. This guy wrote two bits of code for a text input box which is one of the most basic GUI components there is after buttons.

sovietmudkipz 5y ago
>> But the entire point of having a "cross-platform" GUI toolkit is that you don't have to do that. That's still true for flutter but it all depends on the requirements of the project. In the OP article, the point was to make something that is "native-looking" to Mac OS and Windows OS. This requirement does imply a requirement for different looking and behaving UI. Lose that requirement and then you can get the non-fractured code base back. Perhaps you may reply "the framework should do that translation for you," to which I would respond "maybe you're right." It would be nice as a framework user to offload this type of work to the framework authors. Conversely, from the perspective of the framework authors they get to work on other features if they offload this type of work to the framework users. I suspect the deeper questions for both framework users and authors is "who owns this work?" "what tradeoffs are users willing to make to gain this framework features?" and "what does joint ownership of this requirement look like?" Different framework communities will arrive at different answers. At the end of the day as a pragmatic programmer you just kinda have to hack around the edges to smooth everything out for the end user.
swman 5y ago
In my projects when I need independent UI per platform I just extract the logic to a new component that renders the right thing for each platform. That way my views aren’t filled with conditionals the component handles it.
smasher164 5y ago
And this is why I think the goal of a cross-platform toolkit is misleading. If your language/library/compiler make it really ergonomic to conditionally target code for a platform, then you get the benefit of keeping your business logic in one place, and the pain only with testing the application. Usually this is not the case, since interfacing with Cocoa is so different from Win32, for example. However, one shouldn't conflate that difficulty with the difficulty of testing an app across platforms.