DEV Community: Jake Bloom

Using Share Sheets on iOS and Android

Jake Bloom — Fri, 12 Jun 2020 15:27:09 +0000

A Share Sheet is a really powerful feature that's available on pretty much any phone today. If you are an application developer and you want your users to be talking about your product, a compelling experience with a well set up Share Sheet can help unlock network-effect growth.

What is a Share Sheet and why should I use it?

Share Sheets are interfaces in both iOS and Android that allows you to share content from your app to another app. For example, in your Photos app, you can select an image and then share it to other apps like Instagram, your mail app, your messaging app and plenty more.

The actual logic behind the Share Sheets is handled by the operating system, all you need to do as an app developer is tell it to open. Share sheets are set up this way so you don't have to update your app code to handle new apps that can share the same content. You send the operating system your content to be shared, and it will tell the user where it can be shared to.

On iOS, the Share Sheet looks like this:

And on Android, it looks like this:

How do I do it?

Lets get into some code!

iOS

On iOS, the Share Sheet comes in the form of a view controller that you need to programmatically create and present to the user. It is called UIActivityViewController, and for simple use cases, it is pretty easy:



let textToSend = "This is some text that will be exported to another app!"
let activityViewController = UIActivityViewController(activityItems: [textToSend], applicationActivities: nil)

currentViewController.present(activityViewController, animated: true, completion: nil)

With that code in place, this is what we see:

And that works great for text, but what if we wanted to share an image?



let image: UIImage = getImage()
let activityViewController = UIActivityViewController(activityItems: [image], applicationActivities: nil)

currentViewController.present(activityViewController, animated: true, completion: nil)

It works great, but looks a little plain. It is possible to customise the Share Sheet with a title, description and thumbnail though, by passing the controller an instance of UIActivityItemProvider instead of just raw data:



class ShareImage: UIActivityItemProvider {
  var image: UIImage

  override var item: Any {
    get {
      return self.image
    }
  }

  override init(placeholderItem: Any) {
    guard let image = placeholderItem as? UIImage else {
      fatalError("Couldn't create image from provided item")
    }

    self.image = image
    super.init(placeholderItem: placeholderItem)
  }

  @available(iOS 13.0, *)
  override func activityViewControllerLinkMetadata(_ activityViewController: UIActivityViewController) -> LPLinkMetadata? {

    let metadata = LPLinkMetadata()
    metadata.title = "1 Image"

    var thumbnail: NSSecureCoding = NSNull()
    if let imageData = self.image.pngData() {
      thumbnail = NSData(data: imageData)
    }

    metadata.imageProvider = NSItemProvider(item: thumbnail, typeIdentifier: "public.png")

    return metadata
  }

}

...

let image: UIImage = getImage()
let item = ShareImage(placeholderItem: image)
let activityViewController = UIActivityViewController(activityItems: [item], applicationActivities: nil)

currentViewController.present(activityViewController, animated: true, completion: nil)

And there you have it! It is also possible to send multiple data objects to the Share Sheet, or specify which apps can access the data using the applicationActivities parameter.

Android

I've found that doing this on Android is more complex than on iOS, mainly due to how Android deals with file permissions. Basically, you have to set the permissions of the file you want to share manually, whereas in iOS it was handled automatically.

In android, you need to designate the class you are going to be calling from as a FileProvider, and specifying which files it is allowed to access. You do this by specifying the class in the AndroidManifest.xml file:



<activity name=".MainActivity">
  <provider
    android:authorities="com.package.ClassName"
    android:exported="false"
    android:grantUriPermissions="true"
    android:name="androidx.core.content.FileProvider">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_paths"  />
</provider>

And then creating a new directory called xml and a file in it called file_paths:



<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <files-path name="my_images" path="images/"/>
</paths>

Note that you might need to use a different tag than files-path depending on where your files are stored. If you are using temp files, you might need to use cache-path. For a full list of what you might need, see the android docs here

Now, inside the class that we specified in the provider above:



File file = getFile()
Uri uri = FileProvider.getUriForFile(getContext(), this.getClass().getName(), file);

Intent intent = new Intent();
intent.setAction(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_STREAM, uri);
intent.setType("MIME_TYPE_OF_FILE");

Intent shareIntent = Intent.createChooser(intent, "Share File");
shareIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_GRANT_READ_URI_PERMISSION);

startActivity(shareIntent);

Executing that will open up the Share Sheet and send your file on it's merry way. I haven't found a consistent way to customise the Share Sheet on Android like we did earlier on iOS, but if I do, I'll update this post.

Creating Static and Dynamic Libraries for your C Programs

Jake Bloom — Sat, 03 Nov 2018 20:27:32 +0000

G'day world! This is my first post here on dev.to. I'm stoked to be here, and today, I'm going to talk about code reuse in the C/C++ world.

Bill Gates never actually said "Hire the laziest person for the job, because they will find the easiest way to do it", but the sentiment certainly rings true.

If you're a Civil Engineer, you can't reuse a pylon from a previous bridge in a new building, but a Software Engineer can reuse code from a previous project. This is a huge productivity win, and we should be leveraging it as hard as we can.

When dealing with C or C++, there are two general ways of reusing code between projects - static libraries and dynamic libraries.

Static Libraries

A Static Library is just a series of object files (.o files) that have been archived together. On Windows, you'll see them with .lib extensions, whereas on linux systems they have .a extensions.

For example, let's say we have a project called "Wave" that makes web requests in C. We have two .c files, waveRequest.c and waveResponse.c. In order to create and use a static library, we do the following:

> # Create the object files
> gcc -c -o waveRequest.o waveRequest.c
> gcc -c -o waveResponse.o waveResponse.c
> # Create the Static Libaray
> ar rcs libWave.a waveRequest.o waveResponse.o
> # compile your code with the library
> gcc -o main main.c -lWave # The compiler adds the "lib" and ".a" itself

Now, whenever you want to use your Wave library, you can copy the libWave.a and compile it into your project. This has a few advantages:

We are reusing code
We can write unit tests for our Wave Library and be confident that it will work everywhere
If the library gets updates and is not backwards-compatible, the older version is still compiled into your code

However, there are some disadvantages to using static libraries:

Copying the .a file around to different projects is kinda clunky and doesn't feel like a nice workflow
If the library is updated and you want to move to the new version, you need to recompile your project
You might not be using all the functionality of the library, so compiling all of it in with your code could be a waste of space

So what do we do if we don't want to compile in the static library to our own code?

Dynamic Libraries

While you have to compile in your static library, the dynamic library is stored in one place and loaded into multiple programs at runtime (think of common C libraries, like stdlib, stdio and assert). They typically have .so file extensions (or .dll in Windows) and don't require any extra compile flags for use.

Using our Wave example, and assuming we have a Wave.h file, you can create a dynamic library as follows:

> # Compile the object files
> gcc -fPIC -c -o waveRequest.o waveRequest.c
> gcc -fPIC -c -o waveResponse.o waveResponse.c
> # Create the dynamic library
> gcc -shared -o libWave.so waveRequest.o waveResponse.o
> # Copy the library to where it can be included
> cp libWave.so /usr/local/lib/libWave.so
> cp Wave.h /usr/local/include/libWave.h

Now, there's a bit going on here, so let's unpack it. Firstly, we are compiling our object files with the -fPIC flag, which means "Position Independent Code" - this will remove all absolute address references from the code and use relative addresses instead, allowing us to reuse the code across multiple projects without having to recompile it.

We are also copying our library and header files to a place where the compiler knows to look for library and header files. This might be different on your machine, for info on osx, look here and for linux you can use ldconf.

We can use our wave library in code as follows:

#include <Wave.h>

int main(int argc, char* argv) {
    wave_make_request("https://dev.to");
    return 0;
}

Now that we are using the dynamic library, we get the following benefits:

Whenever our library is upgraded, we automatically get the new version
We don't have to copy files between projects
We don't have to remember to compile in the library, just include it! But there are some drawbacks too:
If updates are made to the library that aren't backwards compatible, you will probably end up with a runtime error
On lower memory machines, paging between the dynamic library and your application code might cause a hit to your app's performance.

So there's my summary of static and dynamic libraries! Hopefully you found this useful, and we can all continue to be lazy.

Cheers