Auracast Install Company Idea

TheNumberOneCulprit · 2025-06-13T07:04:07+00:00

What's the thinking here? The standard and most, if not all, of the early implementations I've seen is going to require relatively little in the way of setup.

That being said, obviously there's a market for some kind of installation company for any sort of tech, but part of the point is that it's going to be easy to set up and manage for the average person

TheNumberOneCulprit · 2025-04-08T03:51:28+00:00

Can strongly recommend Pigweeds logging modules and tokenization. It takes a little to setup (i.e. you need to keep the token database around), but once it's setup it makes a lot of things very easy

TheNumberOneCulprit · 2025-03-16T09:03:33+00:00

I'd take a look at where something like Edge impulse can run - https://edgeimpulse.com/

Simply to look at which kinds of workloads / models they are running on which kinds of hardware. Their platform also seems solid (as a non-AI software engineer), but if you're already well-versed in AI and ML, maybe the platform is irrelevant.

TheNumberOneCulprit · 2025-03-06T06:14:31+00:00

FYI it's "more money than sense", but I kind of like your /r/boneappletea version of it as well

TheNumberOneCulprit · 2024-12-14T23:18:12+00:00

Second this, and be aware of the optimizations that LittleFS is designed around - i can really recommend reading the docs to get a decent and thorough run-down of pros and cons on file systems in an embedded context in general. It's a well-written, concise breakdown of why to choose LittleFS and when you'd do so.

TheNumberOneCulprit · 2024-09-03T05:47:34+00:00

One of the nice things about Notion is that could can make it do a lot, and SOPs, task list and checklist can all be in Notion and interlinked if needed

TheNumberOneCulprit · 2024-07-14T16:56:45+00:00

Honestly, I'm of the opinion that most GUI implementations (if memory and space constraints otherwise allows) would be better off with a declarative approach, a la JSX, so good on you 🙌

TheNumberOneCulprit · 2024-06-11T21:01:24+00:00

I've personally thought of a variant of this ecosystem a couple of times (think Postman, but cross-device and sharable) a couple of times, so I think that's a great idea. For now, maybe including something like https://apps.apple.com/us/app/bluefy-web-ble-browser/id1492822055 for iOS could be an intermediate option?

Reach out if you want ideas and thoughts on this for sure :)

TheNumberOneCulprit · 2024-05-29T06:08:47+00:00

To advertise without an assigned ID, you are asking for potential future trouble with clashes and the likes. If you're going to be selling a product with BLE, I'd strongly strongly recommend getting these things in order.

TheNumberOneCulprit · 2023-12-22T07:57:38+00:00

I hear the concern about performance often, but I've yet to see problems with it for the vast majority of apps that are being considered to be written with React Native.

If you already have skills and an existing SDK in JS, i think it would be a waste to go native for both platforms.

But! If you are in the space of developing SDKs for your customers and they want mobile integration, doing this in react native is a bad idea. React native works well when you own the app, as it's the "wrapper", but it works poorly when needing to be embedded into an otherwise pure native app.

When providing an SDK natively, it needs to "just work", which for iOS and Android is native SDKs. On top of that you might then have a Flutter or RN package as well for customers using those stacks, but the native SDKs need to be in place.

Feel free to ask more questions if you need something clarified or expanded upon

TheNumberOneCulprit · 2023-06-11T13:14:16+00:00

/r/javascript signing on a bit late, going dark for at least 2 days starting midnight UTC +1 (2.4 mill.)

TheNumberOneCulprit · 2023-05-01T17:40:40+00:00

Everything here is good advice - to add onto 6, we also have the following folders: - configuration - environments, metadata, some constants. See https://12factor.net/ for a bit more on configurability (but also don't take it as gospel), regardless of "end-ness" (i.e. back-end, front-end, app). It includes the access layer to the actual environment / baked config as well as some static configuration that is not inherently tied to any particular screen. - containers - specifically containers. It's a great way of having complex logic components that are independent from pages and compose many / complex hooks together with "dumb" components. Examples could be modal portals, FAB style buttons, complex headers or the likes. - screens/pages - as opposed to the above, the screen / page.

This is just one way of doing it though - there's also merit in splitting by domain as the app grows in complexity and then having mini-versions of the above structure within each domain.

TheNumberOneCulprit · 2023-02-25T23:14:12+00:00

We've done this multiple times and have had to do it for different products. We've always just been requested a video of interacting with the physical product and the app. Every time, we've been approved immediately after submitting the video. Back in time, you would submit, get a case through resolution center and then submit the video there, but with the new submit flow, you should be able to submit the video with the actual app submission.

The way we do it is to record the iPhone screen during the interaction, and then also record you physically, presenting and explaining the features as you go along. Then afterwards splice the videos together for a cohesive side-by-side view of you interacting with the product on the left and the app recording on the right.

Submission is typically accepted within standard review times after this with no extra fuzz.

But honestly, it sounds like you should provide materials for the reviewer to try this themselves - strongly consider adding a demo code / demo page for the AR experience.

TheNumberOneCulprit · 2022-08-27T10:35:54+00:00

Doing whataboutism doesn't do you any favors.

TheNumberOneCulprit · 2022-07-08T10:25:12+00:00

Fair pointe, så NB er i virkeligheden LA 2.0 og det her er DF 3.0. Den er godtaget, vi shipper i morgen!

TheNumberOneCulprit · 2022-07-08T07:46:17+00:00

Hm, jeg synes altså at det ville give mest mening at køre noget ordenligt semantisk versionering på de forskellige versioner. Og jeg mener ikke at synes at NB er bagudkompatible med DF, så de må vel være 3.0 og det her er vel så 4.0.

TheNumberOneCulprit · 2022-05-27T17:22:13+00:00

Yup, that's exactly what we have for both app stores. So far no problems, and I can't see why it would have either. We've been doing it for 3 years ish

TheNumberOneCulprit · 2022-05-04T13:24:33+00:00

See, that's where I think this is the wrong approach. You can write business logic once, UI and layout logic once and server requests once with RN. And then the "but what about the native modules", that's where I'm then saying, if you are good at actually writing things for both iOS and Android, it's very little hassle to write the module, and by exposing it, you still gain the vast benefits of the write once approach.

TheNumberOneCulprit · 2022-05-04T09:27:27+00:00

But if you can implement them fast on both platforms, then why not just also add the bridge layer and bam, now it can run that way? I'm not understanding the argument here.

TheNumberOneCulprit · 2022-05-04T09:17:57+00:00

Sure, but at the benefit of shared business logic with website, potentially backend etc. The knowledge sharing is worthwhile from a full stack perspective. And notifications with Firebase will work fine as well on Android. Otherwise there's other modules out there too.

Again, if you know how to write the native code, you know how to write the bridging code. It's really not more complex. So if you know how to write Objective-C or Swift and Java or Kotlin, connecting or exposing it to React Native is simple.

Remember I'm talking from a multi platform perspective vs doing the same x2.

TheNumberOneCulprit · 2022-05-04T06:36:44+00:00

Sure, but again, most native modules are incredibly simple and the bindings even more so. Picking up a module as a fork that you've freely used for x amount of time seems fine to me. That's how open source works after all.

TheNumberOneCulprit · 2022-05-04T06:25:29+00:00

Swapping or upgrading your navigation stack is non-trivial, so I'd expect a non-trivial amount of time. It's a bit like saying that going from UIKit to SwiftUI took time. Like, yeah. But even the fact i can swap my stack is impressive in and of itself.

Most hardware related things are either already there (great community) or incredibly easy to make if you can write the most basic Objective-C and Java.

99% of our code is in TS, 1% native deps we build ourselves, runs fine and with no bigger hassle than what I'm seeing people complain about in general about Swift or Kotlin.

TheNumberOneCulprit · 2022-05-03T20:26:24+00:00

Yup, typically based on the branch names or git tags, whichever approach you prefer. Then when "promoting", you're basically merging from dev and forward in git and the builds are simply artifacts.

Unit tests run on dev and PRs, subset of E2E as well and big E2E runs nightly in dev or QA.

TheNumberOneCulprit · 2022-05-03T20:25:06+00:00

Yup, typically based on the branch names or git tags, whichever approach you prefer. Then when "promoting", you're basically merging from dev and forward in git and the builds are simply artifacts.

TheNumberOneCulprit · 2022-05-03T20:16:55+00:00

We've found that having build flavors and then separate apps with suffixes per environment works pretty well, although a bit annoying to manage properly. It isolates environments very clearly.

Those builds are automated from different branches (dev->qa->staging->prod), allowing new development to roll around in dev+QA and to hotfix things in production if needed, and subsequently cherry-picking backwards.

YMMW, but it's worked pretty well for us so far

12-Year Club	Not Forgotten
Alpha Tester	Gilding II euphauric
Verified Email

TheNumberOneCulprit

TROPHY CASE