Luka Buljan

We wanted to save ourselves from all the growing pains while working on a new react-native project. To do so, we have created and published an in-house react-native toolkit called skeletor.

Minions! Use the @prototyp/skeletor react-native toolkit! -  Prototyped

A couple of days ago we published our small in-house react-native toolkit called
skeletor.

We wanted to rid ourselves of any/all growing pains you have when working on a
new react-native project, whether it’s building screen layouts, handling forms,
animating stuff on screen or the usual platform-specific pains. So, what did we
create?

Well, something for everything, with a very simple concept behind it all — Make
my code short and to the point.

A (Very) short description
The 4 components
All of the components included with skeletor are built with the idea that you
should not have to create a custom StyleSheet object to modify how they look.
All of the styling props are exposed at the top level props and are optimised so
they do not cause unnecessary re-renders or performance issues if possible.

Screen will help you create a screen layout without having to think about safe
areas, custom backgrounds, status bars etc.

Text will autocomplete your font names (provided you set it up correctly) and
will expose most of what you need to modify how it looks to the top-level props.

Block is, as its name suggests, the building block of all layouts, allowing you
to adjust the spacing, size, alignment and other props directly in its props.

InputFocusScrollView solves an iOS-specific issue where input fields are not
automatically scrolled into position when programmatically focused. Having
struggled with custom libraries throughout our development and with the best
solution out of all of them suddenly started not working correctly, we decided
enough is enough and created our own way to solve this very annoying issue.

The hooks
useForm will handle all your form states and validation so you don’t have to
worry about those other than passing in custom validation rules if necessary.
Full TypeScript support.

useAnimation will reduce the boilerplate code you need to do to create an
animation for an element.

useAnimationTimeline will help you lay those animations out on a timeline of
your specification so they trigger when you want them to trigger and in the
order that you want them to.

useAndroidBackHandler is, as its name suggests, a hook that will handle the
android back button and automatically unsubscribe the custom handler when it is
time to do so (either when it should not be enabled or when the hook is
unmounted).

The best part of it all
skeletor has literally 0 dependencies. All of it was built with react and
react-native. 

You can check the code and examples out here: 
https://npmjs.com/package/@prototyp/skeletor

> Thank you for the time to read this blog! Feel free to share your thoughts about
this topic and drop us an email at hello@prototyp.digital.

Development

Minions! Use the @prototyp/skeletor react-native toolkit!

Discover all the pros and cons of developing audio playback in Progressive Web Application. 

What we learned about PWAs and audio playback - Prototyped



Not that long ago, our company [https://prototyp.digital/] was contracted to
develop an application which placed a large emphasis on users being able to
listen to audio podcasts while browsing the rest of the application completely
uninterrupted or multitask on their devices.

The previous version of the application had a separate, hybrid mobile app that
allowed users just that, but had performance and functionality issues.

Our approach was to use our React + Firebase tech stack to develop a PWA
application, covering all use cases under one flexible, performant code base.

The player
We decided to present the audio player to the user at the bottom of the screen
when an audio track is being played, without blocking any further interaction
with other content displayed on the screen. Also, a condensed version for mobile
screens is presented so that it can be expanded with a button press. A simple
solution for both small and large screens.



Something like thisFeature set
From a functional perspective, there were a couple of features we had to look
out for, such as:

 * Switching tracks from outside the player component itself
 * Setting narration speed within the player
 * A fully functional seek/progress bar
 * The ability to download the audio source
 * Most importantly, background playback on mobile devices

Using React and Redux made most of these requirements a non-issue, with the
default HTML Audio element supporting most of these controls out of the box. It
didn’t take long before we had a functional component ready for testing.





Testing
The requirements to pass testing were the following:

 * Desktop versions had to be able to persist playback even when minimised in
   Safari, Chrome, and Firefox
 * Mobile versions had to be able to persist playback when the application is in
   the foreground, in the background and when the screen is locked, with basic
   media controls showing up on the screen when the application isn’t in the
   foreground.

Results


Android and desktop passed with flying colours in all cases, but iOS - not so
much:

 * Worked only when the application was in the foreground.
 * When added to the home screen, audio playback stopped completely when the app
   was minimised or screen was locked.
 * When opened directly in the browser, audio playback persisted, but sometimes
   lost context and stopped playing.
 * Lock screen controls were spotty at best in both cases, sometimes showing up,
   sometimes not, and sometimes losing context during minimised playback (did
   nothing to audio playback).
 * No option to download the audio file, only open it in another tab.
 * Audio track doesn’t autoplay if there is no user action involved.





The harsh reality
As it turns out, we were fortunate to even have basic PWA functionalities. iOS
12 released a couple of days before testing with improved PWA support on iOS
devices to the point that they were now usable.

Before iOS 12, PWAs didn’t persist their state — for example, with iOS 11, if a
user was to browse the application, minimise it and then go back to it, the app
would restart with a completely cleared cache.

The recent iOS 13 update didn’t fix any of the issues we had with iOS 12 at all,
so all our hopes of Apple fixing the problem in the near future were squashed.

This presented a major problem since a large percentage of existing users had
iOS devices and audio playback is a major feature to them, so Android and
Desktop versions working as intended meant little at this point. Without a
functioning audio player on iOS we could not ship the app. We entered limbo at
this point, with all other features finished. We had to do something about it,
but there was little in the way of helping us.

The next solution
The only thing left for us to try was to wrap the entire web app in a native
shell and publish it on the App Store. The entire idea of having everything in
one solution went flying out the window, but what can you do.

Enter Cordova.

We continued developing the solution and interoping between our web app, Cordova
plugins for background playback, a separate build procedure and generally a
separate project to maintain alongside the already huge PWA app.

We managed to utilise Cordova plugins and a little bit of tweaking to our audio
player component to finally allow background audio playback. After a while, we
had a native app to push to the store.

We tried and got rejected.

We had to implement in-app purchases to get published (because of other sections
in the app allowing purchasing tickets to events). There was no efficient way to
interop our React frontend with a functioning Cordova in-app purchase plugin
from a technical perspective.

Exit Cordova.

At this point, we had a serious discussion on what to do next. We had to go
native for iOS. It felt stupid after all this work and with Android and Desktop
working perfectly, but it was the only thing to do.

The final solution
After seeing what maintaining a Cordova shell around the PWA app would look
like, a native iOS application seems like a much wiser choice when considering
future development.

Enter React Native, the obvious choice. We could reuse most of the functional
components (entire Redux modules) from our PWA solution, which helped us
immensely with a quick delivery. All we had to do was build screens and
components.

It took a couple of weeks to finish development of the simplified media player
app with all the audio player bells and whistles we expected to work in the PWA
version in the first place. Audio download, background playback, fully
functional lock screen media controls — we finally had it all.

Final word
The good thing is that audio player and PWA functionalities work perfectly fine
on Android and Desktop. We built an extremely fast solution with React, Redux
and Firestore that we’re very proud of. However, there are a couple of ugly
aspects of it:

 * There is no control over lock screen media controls, only play and pause
   work.
 * An audio element has to be rendered at all times to not mess up playback
   permissions, no matter if there is an audio source or not. We’ve opted to use
   an audio object instead of an element, that is always rendered in the DOM.

Of course, the ugliest part of this is that iOS is the cause of nearly all the
problems we had with audio playback and we had to build a native app to provide
users the functionality Android allows from the get-go.

The worst part of the whole ordeal is that none of the issues were on our side.

Apple proved to be the blocking factor in all instances, even to the point of an
application not working as intended. As to the reasons for it, we can’t be sure,
but Spotify already has a pretty good idea why PWAs are discriminated against
(which you can read about here: https://www.timetoplayfair.com/ ).

In the end, we lost the unified solution we wanted/the client expected and will
have to maintain two solutions for the foreseeable future. Thank you, Apple.

A word of advice for any future projects involving PWA — if it has anything to
do with media playback, don’t bet on iOS. Think of PWAs as ProblemsWithApple.

What we learned about PWAs and audio playback

Sebastijan Dumančić

Learn how to structure a self-validating and reusable input component that returns both the input value and validation result to its parent.

React Native self-validating input - Prototyped

Sooner or later, you get sick of validating stuff manually.
In order to be more efficient and avoid repetitive work, but still stay flexible
we asked ourselves how do we structure a self-validating and reusable input
component that returns both the input value and validation result to its parent?

There are a couple of marks to check:
 * component must be reusable
 * It should handle validation, label, error messages and everything else
   related to a single input element
 * easily extendable (to handle new requirements)
 * for now, it should handle only simple text input component
 * support for email, password, and other simpler types (name, address, notices,
   etc.)

While not exhaustive, this component should address validation and handling of
basic data input for 90% of forms. For that special cases of weird phone numbers
or special formatted discount code you can always write a custom component.

TL;DR we managed to replace more than 90% of our input fields with this
component throughout the project.

Example
Say you have a screen where you have to enter an email address and name and
validate both.

Something like this:

(...)
interface ParentComponentState {
    email: string;
    emailValid: boolean;
    name: string;
    nameValid: boolean;
// specify all state prop types
    [prop: string]: string | boolean | undefined;
}
export class ParentComponent extends React.Component<
    {},
    ParentComponentState
    > {
    state = {
        email: '',
        name: '',
        emailValid: false,
        nameValid: false
    };
    
    handleSubmit = () => {
      const { email, name, emailValid, nameValid } = this.state;  
      const formValid = emailValid && nameValid;
if (formValid){
        // Do something with name & email
      }
    }
    
    render() {
        return (
            <ScrollView contentContainerStyle={theme.scrollView}>
                <Button title="Submit" onPress={this.handleSubmit}/>
            </ScrollView>
        );
    }
}
(...)

As said above, we wanted to avoid writing handlers for each specific input type.
After all, you do only need two handlers — to set the value and validation state 
and one for submitting everything.

(...)
handleSetValue = (prop: any, value: string, isValid: boolean) => {
  this.setState({
    [prop]: value,
    [`${prop}Valid`]: isValid
  });
};
  
handleSubmit = () => {
  const { email, name, emailValid, nameValid } = this.state; 
  const formValid = emailValid && nameValid;
if (formValid) {
    // Do something with name & email
  }
};
(...)

These two methods, together with invoking the actual component and passing
neccessary props (shown below) are everything that’s required in the parent
component.

<ValidatedInput
  value={name}
  propName="name"
  placeholder="Your name"
  label="Your name"
  editable={!somethingIsHappening}
  changeCallback={this.handleSetValue}
/>
<ValidatedInput
  value={email}
  propName="email"
  placeholder="Your email"
  label="Your email"
  editable={!somethingIsHappening}
  changeCallback={this.handleSetValue}
validationType={ValidationMethod.Email}
/>

Now, the input component. You will have to replace styles with your own in the
code.

(...)
interface ValidatedInputProps extends TextInputProps {
  value: string;
  propName: string;
  label?: string;
  validationType?: ValidationMethod;
  minLength?: number;
  optional?: boolean;
  exists?: boolean;
  compareValue?: string;
  emptyErrorText?: string;
  invalidErrorText?: string;
  changeCallback: (prop: any, value: string, isValid: boolean) => void;
}
interface ValidatedInputState {
  isValid: boolean;
  isEmpty: boolean;
  focused: boolean;
}
export enum ValidationMethod {
    Email = 'EMAIL',
    Date = 'DATE',
    Password = 'PASSWORD',
    Comparable = 'COMPARABLE'
}
export class ValidatedInput extends React.Component<
  ValidatedInputProps,
  ValidatedInputState
> {
  state = {
    isValid: true,
    isEmpty: false,
    focused: false
  };
componentDidUpdate(prevProps: ValidatedInputProps) {
    const { exists, value } = this.props;
    if (prevProps.exists !== exists) {
      this.validateByType(value);
    }
  }
getEmptyErrorText = () => {
    const { label, emptyErrorText } = this.props;
    return emptyErrorText
      ? emptyErrorText
      : label
        ? `${label} is required.`
        : `This field is required.`;
  };
getInvalidErrorText = () => {
    const { label, invalidErrorText } = this.props;
    return invalidErrorText
      ? invalidErrorText
      : label
        ? `${label} is invalid.`
        : 'Value is invalid';
  };
handleSetValue = (event: any) => {
    const value = event.nativeEvent.text.trim();
    this.validateByType(value);
  };
validateByType = (currentValue: string) => {
    const {
      maxLength,
      validationType,
      optional,
      compareValue,
      changeCallback,
      exists,
      propName
    } = this.props;
    
    const defaultMinLength = optional ? 0 : 1;
    let { minLength } = this.props;
    minLength = minLength || defaultMinLength;
    
    let isValid;
    switch (validationType) {
      case ValidationMethod.Email:
        isValid = this.validateEmail(currentValue);
        break;
      case ValidationMethod.Password:
        isValid = this.validatePassword(currentValue);
        break;
      case ValidationMethod.Comparable:
        isValid = this.validateComparable(currentValue, compareValue!);
        break;
      default:
        isValid = this.validateDefault(currentValue, minLength, maxLength);
        break;
    }
const isEmpty = optional ? false : !currentValue;
    if ((isEmpty || exists) && !optional) {
      isValid = false;
    }
this.setState({
      isEmpty,
      isValid
    });
changeCallback(propName, currentValue, isValid);
  };
validateEmail = (value: string, exists?: boolean) =>
    validation.EMAIL_REGEX.test(value);
validatePassword = (value: string) => {
    return (
      value.length >= validation.PASSWORD_LENGTH_MIN &&
      value.length <= validation.PASSWORD_LENGTH_MAX
    );
  };
validateComparable = (value: string, compareValue: string) =>
    value === compareValue;
validateDefault = (value: string, minLength: number, maxLength?: number) => {
    return maxLength
      ? value.length >= minLength && value.length <= maxLength
      : value.length >= minLength;
  };
handleFocusEvent = () => {
    this.setState({
      focused: true
    });
  };
removeFocusState = () => {
    this.setState({
      focused: false
    });
  };
render() {
    const { isValid, isEmpty, focused } = this.state;
    const { label, value } = this.props;
    
    return (
      <View>
        {label && (
          <Text
            // style={ focused ? FOCUSED_LABEL_STYLE : undefined }>
            {label.toUpperCase()}
          </Text>
        )}
        <TextInput
          // style={focused ? FOCUSED_INPUT_STYLE : DEFAULT_INPUT_STYLE}
          value={value}
          onFocus={this.handleFocusEvent}
          onBlur={this.removeFocusState}
          onEndEditing={this.handleSetValue}
          {...this.props}
        />
        {isEmpty && (
          <Text>
            {this.getEmptyErrorText()}
          </Text>
        )}
        {!isValid &&
          !isEmpty && (
            <Text>
              {this.getInvalidErrorText()}
            </Text>
          )}
      </View>
    );
  }
}
(...)

As you can see, the component props interface extends the default TextInput 
props, which means you can pass any default TextInput prop through the component
and it will be applied internally.

The value change is triggered in the onEndEditing input event → every time the
user submits / ends editing the value in the current input field. This will
validate and update the input as soon as the user is done entering the content.
This way the validation doesn’t trigger prematurely and doesn’t give validation
errors while the user isn’t finished with editing the input value.

Using the changeCallback function, the value of the input and it’s validity are
propagated back to the parent component.

Now, about the custom props:
 * propName = the parent component prop name you update with the input.
 * validationType = what kind of validation type is necessary
 * changeCallback = the handler the component passes it’s internal value to
 * optional = if this is set to true, input validation is disabled. Default
   value = false
 * editable = “false” disables editing the value if an action is performed such
   as submitting data to an API
 * exists = for passing let’s say, a userExists property in case you’re checking
   if an e-mail is already in use. Use with e-mail validationType only.
 * minLength = minimum character length
 * compareValue = used exclusively when validationType is set to
   ValidationMethod.Comparable. Use to pass value to compare the input value
   against.
 * value = the input value passed from the parent component.
 * label = display a custom label above the input. Leaving this empty hides the
   label.
 * emptyErrorText = custom error text when the value is empty
 * invalidErrorText = custom error text when the value is invalid

And there you have it. You can include the ValidatedInput component anywhere and
it’ll self validate every time based on the passed properties. Of course, there
is room for improvement, but it’s extendable and simple to use.

Best of all, at ~250 LOC for a whole ValidatedInput component, it is a whole lot
less than libraries such as informed
[https://github.com/joepuzzo/informed#readme] (which can handle a lot more than
this though). Still, we consider this a win.


--------------------------------------------------------------------------------

Interested in working with us? Drop us a line at hello@prototyp.digital. We are
always interested in new projects and people.

AuthorLuka Buljan

Start a Project