After we finish the Windows update, the plan is to write small phone/pad apps that will talk to it. Builders are mobile, and would love access to the accounting file in the office. Those apps will each do just one thing (e.g. enter a purchase or check an estimate). Swift and the current Cocoa will work great for those. No need for any C++. One screen or maybe a couple. Not much interface. I don't know quite what the network technology will be yet, but phone-to-desktop will have advantages over pure cloud-based apps. Cocoa and iOS seem strong at passing data over the Internet. We'll do iOS first, then subcontract matching Android apps later.
Desktop business apps are more complicated, and that's where Cocoa failed for us. Cocoa probably is difficult for any code base that does something complex, and wants to be cross-platform for the model layer. It would be insane for us to write payroll code in two different languages. Not just the programmer time, it's also a lot of extra testing and debugging. Twice the maintenance, forever. At the beginning we assumed that the hard part would be learning Objective-C, and finding a way to link C++ to it. Those were surprisingly easy. Basic architecture also was easy. Powerplant was pretty much just V, but we evolved into MVC very early on. There already are RecordViewer classes that act very much like a NSViewController, so we just link them. After 3 or 4 months the app was already starting to look and work like the current version. Then we discovered NSOutlineView and MFC's CTreeView, and designed a single-window setup that was much better than our current many-windows approach. At that point we were extremely optimistic. Then began the long slog to get everything to actually work right. NSComboBox was almost perfect, but we needed it to only allow existing items. Apple docs said it was possible but we never got it to work, even with suggestions from this list. So it required a text field, popup and table view, with complex interactions between them. Meanwhile CComboBox in MFC did it right with just a single parameter. Our data entry tables have complicated interactions between cells. Trying to get them to work in a NSTableView burned up almost a year. We finally gave up and changed the interface entirely. Constraints were a constant hassle. Looking ahead to how much detail still needs a rewrite was the last straw. There are still about 40 windows currently made in MW Constructor that will each need a nib and controller. At one week apiece for those, the horizon receded too far. Casey McDermott TurtleSoft.com On Fri, Oct 11, 2019 at 11:35 AM Gary L. Wade <garyw...@desisoftsystems.com> wrote: > Clarification: For long-time Mac and now available in SwiftUI, you can > even write “no” code to do some things with bindings. > -- > Gary L. Wade > http://www.garywade.com/ > > > On Oct 11, 2019, at 8:31 AM, Gary L. Wade <garyw...@desisoftsystems.com> > wrote: > > > > For Mac and SwiftUI, you can even write “no” code to do some things with > bindings. > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
