Property wrappers were introduced in Swift 5.1 and are something that many of us have used when working with the Combine framework and SwiftUI. A couple examples would be @State and @Published. While these things might look like some weird syntax that does magical things, it is good to have some basic understanding of what property wrappers do under the hood and how to use them.
Ever wonder how to change memory pointers during runtime in your iOS app? Probably not, but just incase this is how you do it!
With any long-running software project, the need to educate others on a block of code, architectural design, or business process will likely occur. These knowledge transfers (or KTs as the cool kids call them) are often needed when a developer or subject matter expert leaves the project (sometimes unexpectedly) or when a project wraps up and is handed off to the client.
The goal is simple - make Person A understand something to the same degree that Person B does. And this sounds appropriate, right? Why wouldn’t you educate the team or client on the inner-workings of a project? There’s nothing wrong with the idea; the problem is, knowledge transfers just don’t work (usually).
In a previous post we discussed the benefits of using Apple’s DeviceCheck API to verify that an HTTP request originated from a legitimate iOS device. Now we’ll go a step further and look at the App Attest service, which can establish trust with an instance of an iOS App using keys issued by Apple.
The following pattern is fairly common in other technologies:
try {
doSomethingRisky();
} catch (Exception e) {
logException(e);
throw e;
}
This won’t work in salesforce. By rethrowing the exception (assuming it’s
not caught further up the call stack), the database transaction will
be rolled back - that includes whatever insert or update ws triggered in
logException(e). So how do we ensure that the logging occurs in a separate
database transaction? The answer is a platform event!
Mobile APIs are a common target for attempting to exploit a web server, and there are typically many layers of security built into a web infrastructure. We will discuss how an application server can determine that requests are coming from a legitimate source, in this case a trusted mobile app running on a mobile device.
Apex leaves much to be desired when it comes to mocking callouts to external services. Use of the HttpCalloutMock interface requires that a test author configure mock responses for ALL callouts made through the course of a test’s processing, and this can be quite unmanageable in large or complex projects. There must be a better way… Enter the HTTP Mock Registry.
Frustrated with messy tests and abstraction leaks, we’ve devised a utility that provides a intuitive interface for mocking callouts declaratively as well as a foundation for more modular test suites whenever callouts are involved.
When developing using an SFDX Package Development Model there may be situations where valid code generates an error. We’ll take one small Apex/SOQL example today and use a simple workaround to get this code into the package.
While it’s nice that the Lightning Framework provides a way for Aura components to invoke Apex methods, the code required is a bit verbose. We can do better.
Being able to invoke methods and pass data between parent and child components is critical when building an application structure that is both extensible and easy to use.
One of the basic features of Lightning Aura components is the ability to nest components (components containing other components). Communicating from a Parent Component to a Child Component is easy with Aura.
The ability to mock out components is essential to writing quality tests, especially when you’re dealing with integrations or external API invocation. And let’s face it - the out-of-the-box Stub API provided in Apex is just plain awful. Here’s a lightweight utility I threw together to simplify mocking.