Re: Thoughts on Cocoa source code
Re: Thoughts on Cocoa source code
- Subject: Re: Thoughts on Cocoa source code
- From: Pier Bover via Cocoa-dev <email@hidden>
- Date: Fri, 11 Oct 2019 12:17:29 -0500
>
> 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).
I know this is the Cocoa devs list... but why not make a website?
It would be easier to develop, completely crossplatform, no app store
complications, you would be in total control of your stack, etc.
On Fri, Oct 11, 2019 at 12:10 PM Turtle Creek Software via Cocoa-dev <
email@hidden> wrote:
> 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 <
> email@hidden>
> 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 <
> email@hidden>
> > wrote:
> > >
> > > For Mac and SwiftUI, you can even write “no” code to do some things
> with
> > bindings.
> >
> >
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden