Great Java - Caffeinated Babblings!

Today was my last day of more than 30 years in corporate IT software development work!

My first gig was writing Pascal and x86 assembly language at a nuclear fuel plant called Combustion Engineering. Fun and interesting job with ironic company name given all safety rules to avoid a criticality accident. From there I spent a few years at a railroad doing mainframe assembly (and bit of COBOL). Wasn’t prepared for that job, I remember first day asking why there were two enter keys. Eventually moved into client-server systems written in C.

After that worked for the “local phone company”. Early on I worked on a cross-platform, message-oriented middleware tool that ran on PCs, mainframes, and every flavor of Unix. It was over 30 years old and still running in a few places when I beat it to company retirement. One of my favorite projects from that era was a VOIP prototype. PC client and a phone-line interface card initiating voice calls over the regular phone network before we all used the word “Skype”.

Later I moved into enterprise architecture, rolling out Java-based tools and teaching web development classes I really enjoyed. I’d love to teach again, but that space is shrinking due to AI. I also helped build an internal collaboration platform – including the odd experience of watching legal shut it down one Friday evening, and couple years later helping the CEO start his own blog.

The last few years started to feel like a dark “Black Mirror” edition of Dilbert with knee-jerk culture changes, relocations, and general silliness. In the book The Hitchhiker’s Guide to the Galaxy, Earth is doomed because it’s in the way of a hyperspace bypass. The dolphins know it’s coming and try to warn humanity, unfortunately their warnings get mistaken for tricks performed for fish. Eventually they leave Earth with a farewell message: “So long, and thanks for all the fish.”

Time to swim off toward something more self-directed. So long, and thanks for all the fish!

If you have little or no cellular connection at your home or work location, you’ve probably noticed your battery life is poor and your phone may not switch to Wi-Fi calling, resulting in dropped calls. By using a combination of Siri shortcuts and automations, you can set it up so that anytime you arrive at a particular location, your phone will go into airplane mode but stay connected to Wi-Fi. When your phone is in airplane mode with Wi-Fi on, you’ll still receive calls and texts through the “Wi-Fi Calling” feature. Using the same tools, you can also have your phone automatically turn off airplane mode when you leave that location. It only takes about 5 minutes to set up these Siri tricks!

To get started, you’ll need to create two Siri shortcuts: one to turn on airplane mode and then turn Wi-Fi back on when you arrive at your home, and another to turn off airplane mode when you leave.

Create Two Shortcuts to Turn On and Off Airplane Mode

To get started open up the Shortcuts app if you don’t know where that is, you can pull down to search on your phone home screen and type in the word “shortcuts”. The basic steps are below, click the section to open more detailed instructions if you need the details.

Once you’re done you should have two shortcuts (search for Airplane). You can click on them to try them out. The next step is to run these automatically when you leave or arrive at your home location.

Create Two Automations for Arriving and Leaving Home

Test out Your New Automation

Now it is time to go for a drive or walk and test your setup. Once you get a block from your home location you’ll get a notification your shortcut has run and Airplane mode should be off now. When you return to your home location, you’ll get a notification your automation has run and Airplane mode will be on and your Wi-Fi should be working! 

That’s all you need, but read more below if need help with Wi-Fi calling.

Still have trouble with Wi-Fi calling?

 There are couple of things I’ve had success with.

I recently had a need to write some code for the Kaltura API and the libraries have had a lot of changes since the last time I used them. One thing I found curious was (at least for Java) all API calls are queued making the operation asynchronous. It’s interesting to me that other languages don’t default to this. This may be desirable in some scenarios; however, if you are wanting to take any conditional action, you iI recently had a need to write some code for the Kaltura API, and the libraries have had a lot of changes since the last time I used them. One thing I found curious was that (at least for Java), all API calls are queued, making the operations all asynchronous. It’s interesting to me that other languages don’t default to this. This may be desirable in some scenarios; however, if you are wanting to take any conditional action, you ideally want to wait for the operation to complete. For example, if you want to iterate through the categories and then, depending on the data, take other actions to generate a report, you’re forced to store all the content in memory before processing it. Perhaps you’d prefer to generate your API session ID by logging in rather than using your admin secret, which is highly recommended. The C# examples show all the code using the execute() method with an onComplete method that sets a boolean. The following line after the call does a loop on the boolean with 100 ms of sleep. I’m not sure if the C# API has a queue method; if it does, it seems the developer portal-generated code is wrong and the polling is not required. While I couldn’t find any examples of serial execution of requests in Java, the executor class does have an “execute” method. You just need to massage the code generated by the API tool a bit. It does block until API calls are complete and then returns.

Here is an example of login:

LoginByLoginIdUserBuilder requestBuilder = UserService.loginByLoginId(loginId, password, partnerId, expiry, privileges, otp)
        .setCompletion(new OnCompletion<Response<String>>() {
            @Override
            public void onComplete(Response<String> result) {
                System.out.println(result);
            }
        });

    APIOkRequestsExecutor.getExecutor().queue(requestBuilder.build(client));

// proceed to other API interactions

Obviously you need addition controls here (like C# samples) to know when the request is actually complete prior to doing other API actions. You can rewrite this call to block on completion. This simplifies your code if you have nested logic that iterates through a list of items (each which generate an API call).

Generated Sample Code

LoginByLoginIdUserBuilder requestBuilder = 
 UserService.loginByLoginId(loginId, password, partnerId, expiry, privileges, otp)
        .setCompletion(new OnCompletion<Response<String>>() {
            @Override
            public void onComplete(Response<String> result) {
                System.out.println(result);
            }
        });

    APIOkRequestsExecutor.getExecutor().queue(requestBuilder.build(client));


My Revised Code

LoginByLoginIdUserBuilder userRequestBuilder = UserService.loginByLoginId(loginId, password, partnerId, 86400, "","");
Response <String> userResult = (Response <String>) APIOkRequestsExecutor.getExecutor().execute(userRequestBuilder.build(client));
String ks = userResult.results.toString();

I think the usage pattern is a lot easier, and the code is much more straightforward.

Unfortunately, it seems the code examples, most of the client API, and documentation for the Kaltura developer portal are all code-generated. This allows them to spend less time supporting them, but honestly, I think using the REST endpoints is easier due to the lack of human-readable documents and proper code examples that are tested.