newill.dev

Category: The App Challenge

  • Notic Progress

    I’m about nine months into a six-month app challenge—obviously, a product launch failure, and yet, progress is still being made, albeit slower than I wanted.

    I have learned throughout these months that six months was ambitious and that accomplishing that on a big project requires longer hours each week and sustained effort, which I still need to improve.

    I am still spending some time each week working on Notic, but I think to improve my output I need to consider smaller chunks of work daily rather than a few hours at a time once a week.

    Help has come from a friend who joined the project several months ago. She has helped bring motivation and software engineering help to architect the app. She also helps with many other aspects, such as user stories, db design, and much more, which I am extremely grateful for.

    What I am Working on Now

    At the moment, I am working on the data context for the server side. It currently doesn’t have one and grabs data from the server as and when needed. The data context is being added to abstract server and caching so that instead of grabbing a user from MongoDb, I can grab it from the data context, and that will figure out if it has the item cached or needs to grab it from the server.

    This part is tricky, especially with dependency injection and working generically. Being new to C# and .NET, I need to check tutorials. Many tutorials on data contexts show each type of data having its own data context, such as userDataContext, meetingDataContext, and so on. What I am aiming for is a single server data context so that I can access dataContext.Users or dataContext.Meetings. It almost works, but it’s not quite there yet.

    Other progress that has been made is that user login is almost ready. It hashes the passwords and provides a JWT with claims. We still need to store the JWT and use that on each API call. This is almost working and should be ready soon.

    As soon as login is functioning fully and the data context is added in, I feel progress will accelerate, especially on the frontend of things. When these things are ready we can work in slices and work through the app one step at a time and build the frontend and backend at the same time.

    I’ll provide another update within the week regarding the login and data context. Feel free to ask questions.

  • Switching to C# for Notic Meet

    I have recently been working on a C# .NET project. I like the language and framework. My background is in Objective-C, Swift, Python, and others. Now that I have a year’s experience in C# and .NET, I decided Notic Meet would be written in this language. I also now have a friend helping me with the project. Let me explain a bit about what has happened since I last wrote about Notic Meet.

    (more…)

  • Notic Meet Update

    In my last post, I wrote about setting up domains and getting everything in place that would allow me to write and create the app.

    So far, I have set up notic.cc, running the Twenty Twenty theme. There is no content yet, although that will be coming soon. I have set it up with a static home page and have set it up so that notic.cc/blog can be used for product announcements as well as content about meetings and PMK. This particular domain is being used as the site for the Notic Meet and Notic PKM products. Eventually, there will be a web app and perhaps a community, but those are not in the six-month app challenge that I am doing.

    (more…)

  • Project Planning for Notic Meet

    One thing that I struggle with is the feeling of being overwhelmed when there is a lot to do. To break out of that cycle for the Notic Meet project, my plan today is to make a list of all things that need to be in place so that I can focus on building the app and do those things needed to promote it and build a community.

    Overwhelm, in this instance, comes from a few places in this app challenge. One of them is not knowing SwiftUI as well as I knew it a couple of years ago. This causes me to want to start but not quite know how to start, so I feel overwhelmed, then procrastinate and think I’ll try again later. The fix for that is in place by doing a quick refresher on SwiftUI to remember how it works so that I can focus on building and not trying to remember how to build. Another element will be planning all the features that need to be included in the MVP. Knowing what needs to be done and primarily knowing how to do it should remove friction and help me focus on actual work.

    Another reason for overwhelm is not having everything set up to document and blog about the progress with Notic Meet. Yes, I can write notes in an app on my Mac or iPad, but I need to publish those words online either in blog post form or via an email newsletter. Although I’m blogging the process here on newill.dev, I also have a couple of Notic domains, one of which will be for the Notic products and the other to be the home for a weekly newsletter sent out by email.

    I intend to only spend a small proportion of time on writing content, perhaps an 80/20 split between building the app and documenting. Still, I feel documenting the work is an essential part of promoting it and might have the bonus of helping some of you to launch your product.

    For the content, I have already purchased the needed domains. One of them is this blog which is my personal space for writing about this project and sharing other programming and productivity ideas. Other domains are for Notic Meet/PKM, the products and another Notic domain for the weekly newsletters I want to start sending out.

    I plan that once all of the technical sides are sorted out that I can then focus my time where needed, which is designing and building Notic Meet.

    Regarding the app, I don’t have specific deadlines for when features of the Notic Meet app will be finished except for a product six months from when I wrote the introduction post a couple of weeks back.

    Before I begin, here’s a quick update of where I am at with Notic Meet. Last week I mentioned that I was studying how to use SwiftUI. It has been a couple of years since I last looked at it, and even then, I hadn’t built any production-ready apps with it. Most of my previous efforts were in Objective-C and then Swift. I am still studying SwiftUI, probably about a quarter of the way through. It all makes sense so far and is easy to follow. I still don’t know what problems I will hit with using it for Notic Meet, but I’ll tackle them as I reach them. I expect to be finished a basic overview of SwiftUI in the coming week.

    What Needs to be Done

    Several things need to be in place so that I can make this project work. A lot of it is just setting up and mostly forgetting about, such as creating a GIT repo with the new project, setting up WordPress, setting up an email list and so on. The items below are in no particular order.

    One of the first things I have done is get this blog, newill.dev, up and running. This is where much of my blogging will go and will be a mix of information about how the Notic Meet project is going and other technical-related things. Now that the blog is running, I have a quick and easy place to write my content. At the moment, I don’t care about design. The theme used here is Twenty Twenty-One and comes as standard with WordPress. I made a couple of tweaks but left it primarily as is. This will do for now. At some point in the future, when I have a more healthy amount of content, I will start putting up menus with links to categories to make navigating it more accessible. Still, because this is only the fourth post, there isn’t much sense in me trying to guess how users will navigate the site.

    Another important step, which I took a while back, was to register the domain names. One domain will be a place for the products, both Meet, PKM and others that might happen in the future. When a web-based version comes along, it will also be home to the login and product pages for each product. The other domain will be used for my general interest in meetings, planning, and personal knowledge management. It will likely be used for a weekly newsletter about those and will link to any products in this field.

    Speaking of weekly newsletters, I need to plan a way of tracking interesting articles and products in this space so that I can write about them. Although I will compete with some of the products, I am a firm believer that there is more than enough room in the market for competing products. My product might not be a good fit for many, but I hope some will gel with it and become regular users. To keep a weekly newsletter going, I need to schedule a time to read related articles and automate a way to get articles into some kind of tracking system, potentially a product like Instapaper, where I can just click a button to “read it later”. Of course, with email, I can also schedule newsletters in advance so that in the weeks where things are a little too busy, I can have a newsletter mostly complete so that all I need to do is write a paragraph and hit send.

    Back to the domains, both of the domains will need to have WordPress installed as well as a decision about where WordPress will be installed. Will the newsletters be on a subdomain, a domain in a folder, or mixed? I haven’t decided yet, but I will do so this coming week.

    Like newill.dev, the two Notic domains will initially start with a very sparse and free theme, and as the product ramps up, I will consider spending more time on their design.

    Learning SwiftUI is on my list of things to finish this coming week. When I say learning it, I don’t mean becoming a pro at SwiftUI; I mean knowing enough about the mechanics of it that I can almost comfortably build an app and understand the architecture of how it works. Given that I have known iOS development for around 10 years, mixed with Objective-C and Swift, I don’t expect to spend too much time learning the basics of SwiftUI and catching back up to where I was with it a couple of years ago.

    Task management and issue tracking will be one requirement. Having worked on two types of projects, those that are just made up as we go along and the other where each feature is planned, I much prefer working on features that are planned. So much time is saved by spending a short amount of time planning what a feature does and what it shouldn’t do. This helps to avoid scope creep as well.

    For task management, I have been a long-time OmniFocus user on iPhone, iPad, and Mac. I will continue to use this to track more significant parts of the project that are non-programming such as weekly tasks to find content, prepare content, and so on as well as reminders of when to publish content.

    For issue tracking, I will be using Linear. I came across this a couple of years ago and like the experience, which feels lightweight. It will also help me keep tabs on features and the tasks that belong to the features.

    Another step I need to take is finalising what MVP will be for Notic Meet. At the moment, I have too many features, many of which need to be bumped to a future version of the app, but before doing that, I need to simplify what the app needs to function well and benefit those that use it.

    I plan to finish all of the smaller tasks this week by getting the domains hosted, set up with WordPress, and also setting up signup pages for ConvertKit, which I will use for sending emails.

    I’ll post an update this Friday with my progress.

  • Learning SwiftUI – Again

    I wrote last week about the six-month app challenge I am working on; which is to release an iPad app in the next six months.

    Over the past couple of years I have mostly been working with progressive web apps or in recent times a Maui app written in C#. I haven’t done much at all with SwiftUI for those couple of years, so this week I decided to take a refresher so that I could remember how SwiftUI apps work and are built. Native iOS dev is my favourite, but working on multi-platform codebases has been interesting too.

    With Notic Meet being a SwiftUI-based app, I need to relearn this as I work on it, but I needed a quick refresher so that I could get started.

    What I do remember being reasonably easy is the concept of how views work. I don’t mean to belittle a designer’s role when I say easy. I’m more meaning that the mechanics of using views is relatively simple. Making it look good is the real challenge.

    A SwiftUI app begins in the “YourApp.swift” file which creates a scene with a WindowGroup and within that, the initial view is added. The default is called ContentView.

    YourApp.swift could look like this:

    var body: some Scene {
    WindowGroup {
        ContentView()
    }
}

    ContentView is declared as a struct and conforms to the View protocol which requires a body that returns “some” view. When creating a new SwiftUI file you are given this:

    import SwiftUI

struct Test: View {
    var body: some View {
        Text("Hello, World!")
    }
}

struct Test_Previews: PreviewProvider {
    static var previews: some View {
        Test()
    }
}

    I called this view Test. It has a body that returns some View. Some is an opaque return type, meaning we must return a view. SwiftUI has many views built in, but as long as the view used conforms to the View protocol, then it can be returned. In this particular example, the view being returned is Text(“Hello, World!”) which puts that message in the middle of the screen.

    One question you might have is about “returning” some View. You don’t see the word return in this code. That is because we don’t need it. Just having Text(“….”) is enough.

    The Test_Previews struct is used to create a preview in Xcode to see what your app looks like as you build the view. This returns Test() which is the actual view. Although Test currently has no parameters, if it did we would need to pass in some fake data when we return Test in the preview. I’ll show how that works in a later post.

    The neat thing about SwiftUI is being able to nest views in views. If we want to display more than just text, we can wrap them in a list, a vertical stack (VStack), a horizontal stack (HStack) and others. The example below shows how we can make a static table:

    List {
    Text("Hello, World!")
    Text("Goodbye, World!")
}

    We are still returning the single view, which in this case is a List, but within that list, we have two Text views.

    We don’t need to use the SwiftUI-provided views. This particular view is called Test. We could pull Test into ContentView as follows:

    struct ContentView: View {
    var body: some View {
        NavigationView {
            Test()
        }
    }
}

    In the example above, the Test view is nested in a NavigationView. The NavigationView provides navigation for the project although it is lacking a title which can be added in just after Test as follows:

    .navigationTitle("Test Nav")

    To align text, change style such as colour, font etc… you can apply modifiers. If you add .padding() below one of the Text views you will see a default amount of padding being added around the text.

    Text("Hello, World!")
    .padding()

    I found this part of views very simple to follow. You return a View. It doesn’t matter what view you return as long as it conforms to View. This way you can build up the look of your app and add in modifiers to change the layout a little more.

    The Plan

    Notic Meet will be using SwiftUI. I am not experienced enough to know if it will work for all that is needed. A lot of UI will be pretty boilerplate. The app will have a simple look and layout. I don’t know SwiftUI well enough to know its weaknesses yet, although I will post my findings as I build the app.

    The next step is to finish relearning SwiftUI because I will need things like core data, and CloudKit, as well as to understand the design patterns of SwiftUI. At the moment I am mostly familiar with just Swift and MVC as well as MVVM. I typically leaned more towards MVVM with my work in Swift in days gone past, but as of yet, I don’t remember too much about the structure of a SwiftUI app.

    I am familiar with @StateObject, @Published, and @EnvironmentObject, but couldn’t explain that without having to study them quickly first. That will come though and I expect by the end of September there will be good progress to see something working for Notic Meet.

  • The App Challenge: Zero to Product in Six Months

    I have been thinking about building a particular product for a couple of years now but just haven’t made, or perhaps kept, the commitment to keep working on it. Rather than keeping to myself, I thought it would be wise to share with the world what I’ll be working on with the aim of being held accountable to someone. As I work through this challenge for the next six months I’ll be sharing what I am doing along the way.

    (more…)