Building an app for handloading...

As long as I'm typing... how about connectivity to the Labradar V2? And of course, as you mentioned above, Android.
I’m very happy to add more radars. The trick is getting my hands on them to figure out how their Bluetooth controls and firmware works.

For the Rangecraft, because I had one, I could connect it to my computer and poke around “under the hood.”

I’ll ask around at the next Saturday range breakfast (or range cleanup day) to see if anyone’s willing to lend me their chrono for a week.

Yeah, Android up next. I’m planning on switching - so it’s time to learn. It's just a big lift at the moment. I wish it wasn't.
 
Been following this thread and am excited, currently everything I am doing is pen and paper which is fine but not so easy to search around in as more notebooks get filled heheh
Thanks for building a better mousetrap!
 
Another quick update, the app is finally being prepped for beta/testing distribution via Test Flight for iOS. If you're not familiar with Test Flight, it's the app from Apple that lets companies and folks like me distribute an app for testing/validation (or new features) before it goes up on the App Store officially. It's a lighter weight review process and the app is free to use for Test Flight users. If you want in on the testing, dm me an email address. I'm going to start with a small cohort for a couple of reasons: a few initial testers (5-10 max) is probably a good initial gauge of what really needs changing/fixing/clarification.

I couldn't resist adding a few last minute changes, focused on a number of test plan patterns.

The (last) major update is that round-robin shot plans are now possible. Let's say you wanted to do something like the OCW testing that's regularly discussed here (and shared in this thread!). Now you can define a number of shots per charge during test plan configuration and, more importantly set the shot plan to run "round robin". This means instead of say a 3 or 5 shot group of one charge weight, you can run through a plan of 3 or 5 shots per charge weight, but going one shot-per-charge at a time and then repeating.

IMG_5791.PNGIMG_5792.PNG

The round robin mode has another trick up its sleeve pertaining to chronograph users.

Borne out of laziness, when doing round robin charge weight testing, I don't want to start and stop sessions on my chronograph. But that means I don't get useful SD/ES calculations. Starting and stopping sessions 60 times seems like a waste of time.

Even if I did, reassembling those sessions seems, uh, not fun.

So, instead, after the test plan is run, the app will download one session (or multiple consecutive sessions). It will then link up each shot appropriately, creating new sessions that properly reflect the shots for a given charge weight (or seating depths – whatever you're testing).

That means I can just dump a chrono session with say 60 shots (20 x 3 shots each) done in round-robin fashion, and still get valid shot groups with SD / ES values.

And because once in a while a chrono will miss a shot, there's even a function/button to mark shots as missed by a chrono.

IMG_5789.PNG

This new feature needs a tiny bit of testing, so I'm going to head to the range once more to make sure it's working properly. It feels like the right final feature before y'all get to try it. It allows folks to run almost any type of testing plan including round-robin plans like OCW, Cortina Method, etc. etc.

And one unnecessary polish requirement, a loading screen:

IMG_5794.PNG
 
Last edited:
What language are you programming in?
This iOS version is using Swift (v5). No cross-platform frameworks. Pure native APIs/UX. For my day job I work in Scala, which is not at all popular, but I love (particularly for the type of work I do). Scala should make the jump to Kotlin for Android-native less painful.
 
This iOS version is using Swift (v5). No cross-platform frameworks. Pure native APIs/UX. For my day job I work in Scala, which is not at all popular, but I love (particularly for the type of work I do). Scala should make the jump to Kotlin for Android-native less painful.
Ugh. Gotcha. The more I work with c++ the more I don't want to work with anything else.

What is your sales plan? You gonna get these guys to help you and then get them to pay you monthly for the rest of their lives or can people just buy once and use it?
 
What is your sales plan? You gonna get these guys to help you and then get them to pay you monthly for the rest of their lives or can people just buy once and use it?
I didn't come here to start a coding holy war, there are enough "my calibre is better than yours" threads to go around. Choose the right tool for the job and also, you do you!

As for the important, and very valid question, is this going to cost anyone money, and how will that work?

The app is not backed by a SaaS cloud service, in fact, there's no telemetry in the app at all by design, so there will be no monthly fee as long as I'm the owner of the app. There is zero data mining, zero calls to external APIs (not reaching out to any cloud services, including user analytics). What you do with it is your business.

Part of that is that I'm personally sick of the wild data collection and want to do things in a way that respects everyone; but there's also a practical benefit: where I go to shoot, there's little to no cellular signal, so an app that phones home, to any home, is useless to me and, I suspect, others.

Additionally, I think it only fair that anyone here that tries out the beta, and helps in any way, can just keep using the beta/test flight versions, for free, forever. I can even make a cohort, with iOS at least, where they get the exact same version as the paid app, so they don't have to keep dogfooding development features. They will need to update/refresh once a year, but that's an Apple limitation not mine.
 
Last edited:
Great work! Your UI really looks good. I am aware of the amount of work required to develop something at this level of quality.

I also learned something in this thread; I thought scala dev were an extinct breed ;-)
 
Why is a 'cartridge' called a 'caliber' in this app?
The two were related enough in load dev that it worked, but it's a fair point. I'll think about where the differences matter in the workflow for a bit.

Update: just poked through a few workflows and code, and you're right, just a miss on my part. Almost everywhere it says calibre it should say “Cartridge”. Under the hood every cartridge has a calibre that controls which bullets are shown (as they have a calibre field as well).

I'm working through the semantic changes now. Words matter. Thanks for pointing it out.
 
Last edited:
Wasn't trying to start a coding holy war. Just sucks to put so much time and effort into something that looks like it will turn out well only to not be able to port it for people who don't reside in the Apple galaxy within the iUniverse.

Your sales plan sounds reasonable and free use sounds like a great bennefit for the guys who help you develope the app.
 
Back
Top Bottom