AutoDialer Project

The AutoDialer project marked the beginning of an unexpected and exhilarating journey into the world of app development for me. My fascination with coding and the realization that an entire application could be brought to life through lines of code ignited my curiosity. My past experiences revolved around hardware, particularly Arduinos programmed with C++, so the prospect of crafting an app using different code structures like “void loop()” and “void setup()” was a thrilling departure from my comfort zone.

And so I began, a search for the next language I would learn.I delved into a sea of YouTube videos, each advocating for platform-specific languages. Swift UI was alluring for iOS development, Kotlin seemed promising for Android, and Java emerged as the go-to for web-based applications. After a moment of pondering, I decided Swift Ui would be the most practical language for me, being as I had an iPhone, and I figured I would spend most of my time developing for the ios platform.

Lucky for me, my uncle Anupam’s unexpected visit became a turning point in my language selection journey. His intervention was timely and insightful. “Why limit yourself to platform-specific languages when there’s an even better alternative?” he asked. His suggestion was Flutter, a name that had me intrigued. My curiosity prompted an immediate dive into research. To my astonishment, Flutter presented itself as the ultimate solution—a language that allowed one codebase to generate applications across multiple platforms, encompassing iOS, macOS, Windows, Android, and even web-based platforms. It was a paradigm shift, and I thank Anupam for introducing me to this game-changing framework.

Venturing into the realms of Flutter, I encountered both triumphs and trials. My journey was enriched by Anupam’s guidance during the early stages of my Flutter learning curve. His patience and expertise in debugging proved invaluable as I navigated the uncharted territories of Flutter development. Equally deserving of my gratitude is FreeCodeCamp.com, an invaluable resource that provided me a 37-hour tutorial. This meticulously crafted tutorial guided me through the entire spectrum of app development, from configuring my terminal environment to the finished product of publishing an app on the App Store, and everything in between.

Flutter, an SDK crafted by Google, proved to be the catalyst behind my idea. Its seamless integration of various platforms, powered by Dart, its underlying language, was a revelation. What further propelled my enthusiasm was Google’s commitment to maintaining up-to-date documentation for Flutter, allowing me to fully understand the language. An indispensable companion throughout my journey was “pub.dev,” a repository flooded with Flutter plugins. Plugins like “Url_launcher” allowed for the seamless integration of Flutter with native system functionalities, propelling my app’s capabilities to new heights.

With every line of code written and every hurdle passed, the AutoDialer project transformed from a mere curiosity-driven endeavor into app development into a testament of innovation. The language barrier that once seemed insurmountable dissolved into a harmonious symphony of code, and the obstacles I encountered became stepping stones to a finished product. As my app development journey continues, I hope I can share that same experience with you.

Installing Flutter

Installing Flutter SDK. Armed with a trove of YouTube tutorials, each promising to guide me through the process. However, as I followed these digital maps, I found myself lost in a labyrinth of errors and frustrations. So I had to ask Anupam for help. Fortunately it seemed to be a quick fix for him, but what I watched and took away most, was his skill of debugging, the thought process, the resources he used, and the logical steps to approach. In contrast to my previous habit of initiating new projects and starting from scratch whenever I encountered a bug, I had now learned to confront these challenges head-on. Armed with newfound knowledge, I confidently ventured into the vast realm of Stack Overflow.

Learning Xcode

During the initial stages of my Flutter Development voyage, I encountered what appeared to be a delicate and intricate realm when it came to crafting iOS applications. It was as if the development process walked on a tightrope, teetering on the brink of fragility. A single deviation from the prescribed code, even a solitary line placed beyond the tutorial’s boundaries, would send the entire app into disarray. It was as though the act of building for the iOS simulator hung by a thread, easily unraveled by the slightest misstep.

Over the passing months, I gradually moved to Xcode while addressing this particular hicccup. More often than not, I found myself navigating this intricate web of issues within Xcode, rather than relying solely on Visual Studio. The reason lay in the distinct approaches of these two tools when it came to error handling. Xcode, like an illuminating but overwhelming guide, would unravel the complexities of the environment for me, with ease expanding the errors and their origins. In contrast, Visual Studio, though functional, would often leave me with the cryptic message that “Dart exited with a code 0,” which, while not entirely unhelpful, lacked the fine grain guidance that Xcode provided.

Installing Cocoapods

As I delved deeper into my Flutter Development journey, I encountered a pivotal crossroads roughly seven hours into the course. The obstacle at hand revolved around Cocoapods, a crucial component for incorporating native iOS code into the Flutter framework. For, my Mac seemed to harbor a stubborn reluctance to embrace this tool, persistently confronting me with the enigmatic error message: “OpenSSL is not available, Install OpenSSL and rebuild Ruby or use non-HTTPS sources.”

I ventured down the paths of attempting to install Ruby first or endeavoring to clone the GitHub repository and manually build it. Regrettably, neither of these strategies bore fruit. For guidance, I scoured the realms of GitHub repositories and delved further into the depths of StackOverflow, hoping to find fellow developers who had navigated the same SSl issue. Unfortunately no one seemed to be able to help…

Migrating to AWS EC2

Faced with these crossroads, I found myself taking a step back, and pondering a critical thought. It seemed that the only viable route left unexplored was to replicate the entire setup on an alternative new platform, specifically an AWS Hosted EC2 instance, a Mac metal in the virtual servers. Gratitude to my dad for gifting me this invaluable Virtual M1 Machine, which proved to be a catalyst in accelerating my development and learning endeavors.

While I had previously orchestrated the Flutter setup on my Mac, revisiting the process on this newfound VM served as a refresher. It enabled me to revisit steps that weren’t applicable in the world of Arduino, such as updating the Path and configuring the SDK location within Visual Studio Code. The crux of the matter lay in the realization that my Mac’s operating system had fallen behind the times, rendering it incompatible with Cocoapods, a fact later stated by their GitHub Repository. In the end, I ventured into the AWS cloud, setting up shop on a virtual Mac to continue my journey.

While the Virtual Machine served as a vital catalyst on my journey, it was not without its own intricate learning curve. The next hiccup lay within the details of the SSH connection to the virtual Mac, manifesting weeks after its initial setup. A perplexing scenario unfolded as the command I relied upon to SSH into the Mac encountered an unexpected blockade. Upon delving into the inner workings of the EC2 setup, a revelation emerged—a whitelist and a blacklist, silently dictating access.

Following this, I discovered that each time our router underwent a restart, the IP address underwent an alteration, rendering my previous SSH configurations obsolete. A new habit emerged; every router restart demanded a synchronized update to the whitelist, allowing my Mac to reestablish its connection with the M1 Mac residing within AWS servers.

Yet, this was not the sole mystery I encountered. Another riddle presented itself when I transitioned to a LAN connection from my Mac to the router. To my bewilderment, again the once-familiar path to SSH into the VM became obsolete. Guided by sheer curiosity, I unearthed a solution that involved mapping the IP address of the router when connected via WiFi to my LAN connection. This subtle maneuver authorised the connection with an mask, making it appear as though it originated from the same source.

Firewall doing its job too well

It appeared that my personal Mac had been safeguarding itself with an active Firewall all along. A spark of realization ignited within me, and suddenly, the pieces of a long-standing puzzle fell into place. It dawned on me that this was the very reason my Airdrop experience had been somewhat one-sided, with my iPhone communicating only in one direction—Mac to iPhone, while the reverse remained elusive.

For countless years, I had attributed this issue to the natural aging process of my Mac, but the truth proved to be far more intriguing. The silent Firewall, acting as a guardian of connections, had been the silent architect of this fascinating phenomenon.

As I continued my journey, another intriguing situation presented itself, offering a pathway to exploration and innovation. The prospect of connecting to the Virtual Machine from a different device, such as a Chromebook, beckoned, albeit with its unique set of considerations. While I recognized that SSH remained a viable option, it came with the prerequisite of installing Linux, a prospect that loomed large, given my limited 32GB of storage.

In my quest for alternatives, I unearthed a gem known as Google Chrome Remote Desktop (GCRD). This ingenious solution opened doors to seamless connections without the burdens of IP address whitelisting or the unpredictability of router IP address changes, especially when I ventured beyond my usual network confines, perhaps to a hotspot in a remote location. What struck me as particularly fascinating was the marked improvement in my user experience when compared to the traditional SSH connection.

Curiosity led me to embark on an investigation. I chose to share my personal Mac’s screen and simultaneously connect to it through my Chromebook. This dual perspective unveiled a subtle but noteworthy phenomenon: Google actively managed the frame rate (FPS) during the streaming process. It cleverly reduced the FPS on the client machine’s end, channeling the resources where they were most needed during streaming. This optimization contributed to a smoother and more responsive experience.

Yet, as with any journey, there were nuances to uncover. I stumbled upon the intricate realm of audio streaming on Mac, where a core challenge emerged. Mac OS, by design, posed restrictions on system audio sharing during screensharing sessions. Instead, it leaned on the microphone to capture and relay the audio. However, my research revealed the existence of workarounds, involving tools like Audio MIDI setup, capable of merging system audio with the microphone line. These maneuvers enabled the sharing of system audio, but with a caveat—applying specifically to software-related screenshares like Zoom or FaceTime, distinct from the Apple ID screenshare employed for SSH into the Virtual Machine. The intricacies of this audio puzzle added a layer of intrigue to my exploration.

Initialising a Local Repository

The subsequent chapter in my journey brought forth a new layer of exploration, centered around GitHub and the enigmatic realm of Private Keys. These keys served as the bridge to set up a local GIT on my machine, enabling me to commit updates with ease. This learning curve not only empowered me to maintain continuous backups of my code within a repository but also bestowed the ability to tag and organize these backups, aligning them with the specific changes I introduced. As an added benefit, it laid the groundwork for a future convenience—seamlessly downloading this code package onto another physical machine for testing purposes. No longer did I need to grapple with the intricacies of syncing changes made on the Virtual Machine (VM) with the codebase on a physical machine; a few lines of terminal code within the VM would update the repository effortlessly.

Troubleshooting IOS Simulator

Yet, as the project unfolded, a distinctive challenge came into focus. The crux of our endeavor revolved around the pivotal feature of “Initiating Calls.” Ironically, the simulator, despite its utility, remained bereft of the very essence it sought to simulate—calling functionality. It couldn’t even emulate a calling experience, a rather conspicuous omission. Undeterred, I embarked on a quest to explore a workaround, realizing that to debug the app’s core functionality, I needed to launch it on a physical device.

However, this journey too encountered its share of roadblocks. Xcode’s ability to build for a physical device hinged on a crucial condition—physical connection via cable between the device and the VM. A new path of research beckoned, leading me to explore applications capable of establishing a serial connection between the physical Mac and the VM. Intriguingly, I discovered products that could bridge this gap, enabling me to view my physical Mac’s webcam as a device within the VM and even recognizing peripherals like the USB-connected mouse. Yet, these solutions came at a cost, prompting me to seek an alternative route.

My next course of action involved borrowing my father’s laptop for the purpose of debugging and testing. This strategy allowed me to split my work into two distinct phases. Throughout the day, I focused on refining the app’s logic and crafting code for seamless communication with Firebase, the app’s database. After midnight, the window of opportunity opened wider—this was the only time my father’s laptop remained available, enabling me to integrate and test the app’s functionalities as a cohesive whole.

The following episode in my coding escapade revolved around the ever-enticing prospect of embracing the latest iOS version, iOS 17. As soon as the Developer Beta for iOS 17 made its debut, my curiosity led me to install it promptly on my phone. However, this seemingly innocuous decision bore unforeseen consequences, particularly when it came to my development environment.

It didn’t take long for the repercussions to manifest. The upgrade to iOS 17, while thrilling, rendered my Xcode 14 environment obsolete. This meant that any attempt to build an app for iOS 17 Beta with Xcode 14 was bound to meet an impasse. The solution lay in the embrace of the Xcode 15 Beta.

The prospect of downloading and installing Xcode 15 Beta beckoned, but the patience required for yet another hour-long endeavor did not align with my determination to forge ahead. Instead, I embarked on a quest within the confines of my house, hunting for the elusive 5G signal with my phone. After a series of determined scans, I finally unearthed a signal. However, there was a catch—it demanded my phone to be affixed to the window for a stable connection.

Yet, this arrangement held promise, as the speeds it offered soared to an impressive 600MBPS. The inconvenience of adhering my phone to the windowpane paled in comparison to the possibilities that lay ahead in the world of iOS 17 development.

While this journey began with soley app development in mind, a vast network of knowledge surrounding it was also made.