Up to this point the primary list-view itself didn’t have a class separate from the main window controller. It’s a simple view controller, it just swaps views – no animation. But I think it needs to be a bit smarter going forward. Not all should be treated equally and this can help save a bit of memory. * The Home timeline should never be freed and should always poll for changes. * Since there are no micro.blog push notifications (yet!?) it might be a good idea to keep the model for the mentions resident so it can for poll. We can post a local app notifications. I hate to use “engagement” 🤮 but micro.blog could use a bit of help keeping new users coming back. Some thought about engagement is a good thing. * All other timelines should be created lazily. We can cache some of the objects to display immediately – but no reason to keep the main view.
- With all that in mind I started the refactor, rounding up the code from the main window controller and jamming it into it’s own view controller class.
- I did some more work on the nav-bar view too since it wasn’t initializing itself correctly in all cases.
View base class
- I continued fleshing out of the my DOM -> View base class so that I can do addSubview and removeFromSubview in my comfortable cocoa way and things behave as expected. I don’t ever have to call
- My View class also has generic steps for loading (in this case template loading), render, and display with async “setNeeds
…” methods. It’s now slightly more functional than the version I use in Stacks – which has slightly different needs and can lean on real cocoa view classes. The new class are slightly less tested … o.k. … ok … so … like not tested at all. 😑 writing unit tests are not my favorite pastime. this is supposed to be my hobby project after all – maybe someday i’ll get serious.
No snazzy gif today. :-( Nothing visual changed. At least not intentionally. :-P
What is this: these are random snippets from my dev journal working on a simple client app for fun. This is a non-serious side project, progresses very slowly, and will probably never see the light of day. The images may not perfectly correspond to the journal entry. In most cases I’ve added them later based on the relative time of git checkins.