Yes, I was also wondering why it's necessary to come up with yet another smart pointer, which you need to learn and which is probably not battle tested.
They also seem to have wrapped the STL, which I think is a big no-no. No real reason to relearn something new if there is an established standard. A modern C++ library shouldn't do that.
I am a member of the Boden dev team. The smart pointer system is actually still a topic of discussion in the Boden team as well. It has a couple of nice properties, like the fine grained control bdn::P gives us over the time when an object is actually destructed. For example, these pointers provide an easy way to ensure that destruction of our View objects happens only on the main thread, no matter which thread released the last reference.
But on the other hand, not using the standard constructs definitely has a cost associated with it. We are happy for your feedback on this issue.
Note that we also think about the idea of transforming P and making it a specialization of std::shared_ptr for objects derived from bdn::Base. That would give us the best of both worlds. Feel free to let us know what you think.
If you want to go down this road, doing mobile cross-platform native, Xamarin seems much more compelling. It is supported by a very good IDE and has proper licensing for distribution on the app stores. https://visualstudio.microsoft.com/xamarin/
One question though for app developers who are experienced in this field- does anybody know the relative running time of native vs managed code on android? Does it matter at all for ux-heavy code? How does the startup time look?
Author here. We’re still in the process of figuring out what the right open-source licensing model for Boden should be. In the long run, development must be financed by a viable business model as Boden is not a hobby project. We’re considering adding a commercial option later, ending up with a dual GPL/commercial license similar to other projects. We’re happy to hear your thoughts about other licensing options!
Boden dev here. Boden currently supports linear layouts (horizontal and vertical). We know that more is needed for a proper UI. Feedback is appreciated - let us know what you would like to see regarding layout options.
Since all widgets are native, you can easily add your own child widgets to the containers. You can gain access to the native view objects via the "View::getCore" method. However, we do not have a good way yet to insert custom widgets into the Boden layout system. That is an area where more work is needed.
Regarding calling platform APIs: since the apps are written in C++ you can call any platform API you like. On Android you can also use the Boden helper classes (bdn::java::JClass, etc.) to make Java calls from C++. On iOS the easiest way is to create an Objective C++ file (.mm file extension). In there you can combine C++ and Objective C code freely.
Why is it that nowadays all kinds of libraries go down the framework path by forcing/encouraging the user to adapt their workflows to use some kind of custom tooling?
I mean look at the readme: Getting Started? Just call "python boden.py new -n AwesomeApp"
Just provide examples in source form with minimal and standard instrumentation (like project files) and leave the rest to the user
I rather like using the custom tooling. It means that if people are following the prescribed procedure, they will always be using the latest version of a project template or some such rather than duplicating a local copy of what might be a hideously out-of-date template.
With Swift, for example, using Swift Package Manager (SPM) to initialise templates means that the syntax in the newly-created project's files is up-to-date, the Package.swift file follows the appropriate naming conventions for whatever version of SPM it is, and it's much more convenient to do `swift init` than to go clone a github repo manually then rename this or that.
It's basically a command-line version of project templates in Visual Studio or whatever, and people generally like those. Sane defaults are nice, but sane defaults with validation are nicer.
Though I agree that it would be nice to just have a blank template available for those who don't want to use the tooling. There should always be a subsection in the Getting Started section that says "clone this repo, and you're good to go. Be sure to clone the repo again when you want to make another project; don't just copy your existing clone!".
Flutter, out of Google is a solution for iOS and Android cross-platform development that includes very fast UI primitives, a edit and continue workflow, intuitive and reactive UI framework, and a nicer high-level language to work with than C++ (Dart).
This would be an unpopular opinion but no-javascript should be a thing everywhere excluding browsers. And hopefully with webasm, it can be a thing on web too
> Native widgets: Instead of drawing widgets that look nearly identical to the platform's design, Boden uses native OEM widgets ensuring that your app will always have a truly native look and feel.
While I fully understand the underlying concept, I don’t understand why so many people seems to be bothered by that anymore; I used to care about that as an Android user, but most of the apps I use everyday on my phone (Twitter, Inbox, Slack, Youtube, even Google Photos or Maps) do not seems to use the pure platform widgets anyway.
Native widgets don't just mean "look". They can also mean "feel". This is particularly true on macOS.
On macOS, I expect certain widgets in order to accomplish certain tasks. I expect that they will respond to mouseover and button presses in a certain way. I expect to be able to use certain key combinations to cause certain widgets to do certain things, I expect keyboard combinations to be able to be redefined in System Preferences.
On the accessibility front, I expect VoiceOver to be able to read what's on screen, I expect it to be able to tell me what a widget's behaviour will be, I expect to be able to get back to where I was using a standard key combo, I expect images to respect colour inversion settings, I expect text to scale according to the system's Dynamic Type settings.
When it comes to handling text; I expect fonts to have the system's native rendering; I expect that Unicode support is complete, I expect macOS' emoji picker to show up; I expect system-wide text replacements, smart quotes, and orthography checking to work as expected, I expect selectable text to show a list of system-wide Services in the context menu, I expect all text to be draggable and handled correctly by the receiver of the drag action.
There are plenty of other things that I can't think of, but this list could get quite long. Suffice to say, Apple put a lot of default behaviours into Cocoa, and apps that (A) don't use Cocoa, or (B) only use Cocoa for drawing but not inheriting behaviours, they don't just look a bit off, they feel _wrong_.
I think we may be immune to this to some extent on mobile, and Windows users haven't known anything other than complete inconsistency, even with Microsoft's own built-in interfaces. But for some of us, if the interface feels wrong, the app goes straight into the Trash.
Author here. The goal of Boden is very much that the applications should look and feel as if they were custom-coded for the specific platform. We also think that custom widgets often fall slightly short of the native feel, as other commenters have pointed out. While it is certainly possible to make them 100% consistent with other native apps on the platform, it is a lot of work to get all the details right. And not all frameworks manage to do that.
We wanted to try a different approach. Why not just use what the platform gives you and always get the right look & feel out of the box? That certainly creates its own challenges, like having to provide a good abstraction layer for the core application code. But you do not have to worry about look, feel, drawing performance, interactions with other OS features and the like. And when the OS changes something then the app is automatically up-to-date.
There are so many hidden behaviors in native widgets that once you get accustomed to, you can't go back any more. Here are a few of the ones:
* Right click the document icon on the title bar to reveal a menu bar for ancestor directories
* Drag the document icon into things like an email client as an attachment
* Support Emacs-style text editing shortcuts such as C-a C-e C-k everywhere, as well as user-defined ones (I added a bunch of other Emacs ones like M-f)
* Trackpad shortcuts such as three finger press on a word to show dictionary and thesaurus
* Drag and drop selected text to move it
* Hold option while selecting text for rectangular selection
There are many others. I get upset if something doesn't work when I know it should work if the app developer is using native controls.
I might be totally off base here, but I get the sense that native widgets have become a skeuomorph for following the common UX conventions of the platform you're running on, with the latter being what brings the real value. The equivalent conventions for web apps and their desktop derivatives are much looser and don't yield as much consistency on which to build effective user expectations and habits. People who experienced the shift can tell something is missing, and the most obvious correlate is the disappearance of native widgets.
Especially when Google itself is promoting Flutter which in a way is a non-native UI framework. I think as long as a framework is performant and implements well the design guidelines of the OS this is what really matters
It's often necessary to make all the native accessibility stuff work.
Sometimes new features come out which will immediately work well with native components, but which require a lot of reworking to work well with something custom. High DPI support is often an example of this.
You could make this exact same framework with rust as the backend instead of C++. I have made a proof of concept MVVM app in rust for iOS and Android.
Instead of binding view models and state you bind the entire platform with bindings for every widget and control. Its not too much work but it is a lot of boring code to write and maintain.
“Boden is written in modern C++11 to make development easy...”
They lost me there. I admit I haven’t done any true C++ in the last few years, bowing at the height of Boost. So I’m curious, did I miss something in the next chapter of “modern” or perhaps the “11” that suddenly made C++ development “easy”?? It was quite capable for sure, but easy, no. Honestly curious. Maybe I’m just not a good enough developer. :/
Yes, it's a way better language than it used to be.
* They added smart pointers that actually work. (std::unique_ptr and std::smart_ptr) Invoking delete is considered a code smell in C++11, and new is considered a code smell in C++14. (because of make_unique and make_shared, added in C++14)
* Dynamic polymorphism (via inheritance) has gone out of style. These days it's templates all the way down, which aren't terrible anymore for a wide variety of reasons that I don't have time to go into.
* Threads and safe locking mechanisms are now actually standardized, so you don't have to use boost::thread. std::async, lambdas, and std::future provide reasonable syntactic sugar around threading, as opposed to manually mucking around with your own thread pool.
* Stuff that used to require library writers to dig around in the bowels of template metaprogramming became a lot easier with `if constexpr` in C++17. Actually that's one of the reasons why templates aren't terrible anymore, sorry for going into it when I said I wouldn't.
Idiomatic C++17 code feels like a completely different language than C++03. Ye olden C++ felt like Java with spike traps and no garbage collector, but idiomatic C++17 feels like... I dunno, Rust without the borrow checker and everything is in an unsafe block. (I'm trying to think of a better example)
(as an aside, there are two different things called "modern c++". I'm pretty sure it's a joke, but it's a terrible one. There's Andrei Alexandrescu's 2001 book Modern C++, and there is are the coding practices that evolved out of the development of C++11/14/17.)
Source: I maintain a ye olden C++ codebase at work, and write modern C++17 in my personal projects. The degree to which they differ is profound. I'm not doing the difference justice.
C++11 is old now, C++17 is the latest version which is pretty awesome. It is a serious undertaking just getting packages linked on a platform like windows. I took a short detour into golang, that was a few months ago; C++20 promises package management via modules instead of the old include system, all the c++ compiler vendors are working on it right now. Until then, i'll stick with go.
[+] [-] int_19h|7 years ago|reply
[+] [-] l33th4x0r2|7 years ago|reply
They also seem to have wrapped the STL, which I think is a big no-no. No real reason to relearn something new if there is an established standard. A modern C++ library shouldn't do that.
[+] [-] hduden|7 years ago|reply
But on the other hand, not using the standard constructs definitely has a cost associated with it. We are happy for your feedback on this issue.
Note that we also think about the idea of transforming P and making it a specialization of std::shared_ptr for objects derived from bdn::Base. That would give us the best of both worlds. Feel free to let us know what you think.
[+] [-] sovande|7 years ago|reply
[+] [-] je42|7 years ago|reply
the example app you get out of the box. it didn't run the dummy tests successfully on either ios or android side (forgot which one).
upgraded to the latest version other issues on the example app.
for me this was already a big no-no. if the tests are failing on the example app.
[+] [-] vtesucks|7 years ago|reply
One question though for app developers who are experienced in this field- does anybody know the relative running time of native vs managed code on android? Does it matter at all for ux-heavy code? How does the startup time look?
[+] [-] Teknoman117|7 years ago|reply
[+] [-] gitoby|7 years ago|reply
[+] [-] elteto|7 years ago|reply
[+] [-] O_H_E|7 years ago|reply
[+] [-] rhodysurf|7 years ago|reply
[+] [-] YetAnotherNick|7 years ago|reply
[+] [-] saagarjha|7 years ago|reply
* How is view positioning handled? Does Boden only allow for “list” layouts?
* Can I use my own native components?
* Can I call platform APIs?
[+] [-] hduden|7 years ago|reply
Since all widgets are native, you can easily add your own child widgets to the containers. You can gain access to the native view objects via the "View::getCore" method. However, we do not have a good way yet to insert custom widgets into the Boden layout system. That is an area where more work is needed.
Regarding calling platform APIs: since the apps are written in C++ you can call any platform API you like. On Android you can also use the Boden helper classes (bdn::java::JClass, etc.) to make Java calls from C++. On iOS the easiest way is to create an Objective C++ file (.mm file extension). In there you can combine C++ and Objective C code freely.
[+] [-] captainbenises|7 years ago|reply
[+] [-] simfoo|7 years ago|reply
I mean look at the readme: Getting Started? Just call "python boden.py new -n AwesomeApp"
Just provide examples in source form with minimal and standard instrumentation (like project files) and leave the rest to the user
[+] [-] zapzupnz|7 years ago|reply
With Swift, for example, using Swift Package Manager (SPM) to initialise templates means that the syntax in the newly-created project's files is up-to-date, the Package.swift file follows the appropriate naming conventions for whatever version of SPM it is, and it's much more convenient to do `swift init` than to go clone a github repo manually then rename this or that.
It's basically a command-line version of project templates in Visual Studio or whatever, and people generally like those. Sane defaults are nice, but sane defaults with validation are nicer.
Though I agree that it would be nice to just have a blank template available for those who don't want to use the tooling. There should always be a subsection in the Getting Started section that says "clone this repo, and you're good to go. Be sure to clone the repo again when you want to make another project; don't just copy your existing clone!".
[+] [-] poidos|7 years ago|reply
[0]: https://github.com/ashampoosystems/boden#1-install-xcode
[+] [-] TheMagicHorsey|7 years ago|reply
[+] [-] pritambarhate|7 years ago|reply
SWT project also does the same in Java Desktop World. But it never really became widely used.
[+] [-] pabl0rg|7 years ago|reply
Does something like this exist in Crystal-lang or Nim? Using native widgets to do cross-platform is appealing, but C++ ...?
[+] [-] dom96|7 years ago|reply
[+] [-] z3t4|7 years ago|reply
[+] [-] GutenYe|7 years ago|reply
[+] [-] nkozyra|7 years ago|reply
[+] [-] vtesucks|7 years ago|reply
[+] [-] setquk|7 years ago|reply
[+] [-] blueprint|7 years ago|reply
[+] [-] YetAnotherNick|7 years ago|reply
[+] [-] esokullu|7 years ago|reply
[+] [-] rhodysurf|7 years ago|reply
[+] [-] esokullu|7 years ago|reply
[+] [-] Signez|7 years ago|reply
While I fully understand the underlying concept, I don’t understand why so many people seems to be bothered by that anymore; I used to care about that as an Android user, but most of the apps I use everyday on my phone (Twitter, Inbox, Slack, Youtube, even Google Photos or Maps) do not seems to use the pure platform widgets anyway.
[+] [-] zapzupnz|7 years ago|reply
On macOS, I expect certain widgets in order to accomplish certain tasks. I expect that they will respond to mouseover and button presses in a certain way. I expect to be able to use certain key combinations to cause certain widgets to do certain things, I expect keyboard combinations to be able to be redefined in System Preferences.
On the accessibility front, I expect VoiceOver to be able to read what's on screen, I expect it to be able to tell me what a widget's behaviour will be, I expect to be able to get back to where I was using a standard key combo, I expect images to respect colour inversion settings, I expect text to scale according to the system's Dynamic Type settings.
When it comes to handling text; I expect fonts to have the system's native rendering; I expect that Unicode support is complete, I expect macOS' emoji picker to show up; I expect system-wide text replacements, smart quotes, and orthography checking to work as expected, I expect selectable text to show a list of system-wide Services in the context menu, I expect all text to be draggable and handled correctly by the receiver of the drag action.
There are plenty of other things that I can't think of, but this list could get quite long. Suffice to say, Apple put a lot of default behaviours into Cocoa, and apps that (A) don't use Cocoa, or (B) only use Cocoa for drawing but not inheriting behaviours, they don't just look a bit off, they feel _wrong_.
I think we may be immune to this to some extent on mobile, and Windows users haven't known anything other than complete inconsistency, even with Microsoft's own built-in interfaces. But for some of us, if the interface feels wrong, the app goes straight into the Trash.
[+] [-] gitoby|7 years ago|reply
We wanted to try a different approach. Why not just use what the platform gives you and always get the right look & feel out of the box? That certainly creates its own challenges, like having to provide a good abstraction layer for the core application code. But you do not have to worry about look, feel, drawing performance, interactions with other OS features and the like. And when the OS changes something then the app is automatically up-to-date.
[+] [-] kccqzy|7 years ago|reply
* Right click the document icon on the title bar to reveal a menu bar for ancestor directories * Drag the document icon into things like an email client as an attachment * Support Emacs-style text editing shortcuts such as C-a C-e C-k everywhere, as well as user-defined ones (I added a bunch of other Emacs ones like M-f) * Trackpad shortcuts such as three finger press on a word to show dictionary and thesaurus * Drag and drop selected text to move it * Hold option while selecting text for rectangular selection
There are many others. I get upset if something doesn't work when I know it should work if the app developer is using native controls.
[+] [-] 0xcde4c3db|7 years ago|reply
[+] [-] jjnoakes|7 years ago|reply
[+] [-] asituop|7 years ago|reply
[+] [-] nitwit005|7 years ago|reply
Sometimes new features come out which will immediately work well with native components, but which require a lot of reworking to work well with something custom. High DPI support is often an example of this.
[+] [-] k__|7 years ago|reply
[+] [-] rhodysurf|7 years ago|reply
Instead of binding view models and state you bind the entire platform with bindings for every widget and control. Its not too much work but it is a lot of boring code to write and maintain.
[+] [-] travisgriggs|7 years ago|reply
They lost me there. I admit I haven’t done any true C++ in the last few years, bowing at the height of Boost. So I’m curious, did I miss something in the next chapter of “modern” or perhaps the “11” that suddenly made C++ development “easy”?? It was quite capable for sure, but easy, no. Honestly curious. Maybe I’m just not a good enough developer. :/
[+] [-] nwallin|7 years ago|reply
* They added smart pointers that actually work. (std::unique_ptr and std::smart_ptr) Invoking delete is considered a code smell in C++11, and new is considered a code smell in C++14. (because of make_unique and make_shared, added in C++14)
* Dynamic polymorphism (via inheritance) has gone out of style. These days it's templates all the way down, which aren't terrible anymore for a wide variety of reasons that I don't have time to go into.
* Threads and safe locking mechanisms are now actually standardized, so you don't have to use boost::thread. std::async, lambdas, and std::future provide reasonable syntactic sugar around threading, as opposed to manually mucking around with your own thread pool.
* Stuff that used to require library writers to dig around in the bowels of template metaprogramming became a lot easier with `if constexpr` in C++17. Actually that's one of the reasons why templates aren't terrible anymore, sorry for going into it when I said I wouldn't.
Idiomatic C++17 code feels like a completely different language than C++03. Ye olden C++ felt like Java with spike traps and no garbage collector, but idiomatic C++17 feels like... I dunno, Rust without the borrow checker and everything is in an unsafe block. (I'm trying to think of a better example)
(as an aside, there are two different things called "modern c++". I'm pretty sure it's a joke, but it's a terrible one. There's Andrei Alexandrescu's 2001 book Modern C++, and there is are the coding practices that evolved out of the development of C++11/14/17.)
Source: I maintain a ye olden C++ codebase at work, and write modern C++17 in my personal projects. The degree to which they differ is profound. I'm not doing the difference justice.
[+] [-] dana321|7 years ago|reply
[+] [-] jhasse|7 years ago|reply
[+] [-] cheez|7 years ago|reply