platform conforming
flutter makes no attempt to provide familiar widgets for a specific platform (unlike react native, ionic, and other cross platform tooling). this has enormous benefits to unified rendering on all platforms, maximum flexibility, and eliminating a whole class of bugs and testing done for each platform. while this is great, many scenarios we want our apps to look and feel like an android or ios app. platty allows you to render ios (cupertino) and android (material) like widgets with minimal effort and maximum control in a unified api.
no more checking for platform inside render blocks to render a cupertinobutton or flatbutton, let platty do the logic for you! want to use bottom tabs in your app that resolve to platform specific ui? no problem!
getting started of platform conforming
use platty to unify render-specific apis for you. the library utilizes the buildcontext
theming apis to propagate platform
information into the widgets.
by default, all widgets conform to the default targetplatform
. it looks up the theme.of(context).platform
for its default.
also, all widgets provide a renderplatform
prop that allows you to choose which one to render (if you wish).
replace materialapp
and cupertinoapp
with platformapp
:
class myapp extends statelesswidget {
// this widget is the root of your application.
@override
widget build(buildcontext context) {
return platformapp(
title: 'flutter demo',
// specify our app theme here. we do the leg work of bridging it to cupertino.
unifiedtheme: themedata(
primaryswatch: colors.lightblue,
bottomappbarcolor: colors.red,
),
home: examplepage(),
);
}
}
platformapp
unifies all of the same properties between materialapp
and cupertinoapp
to allow both instances of widgets in the hiearchy and
switching styling based on
platform conforming
flutter makes no attempt to provide familiar widgets for a specific platform (unlike react native, ionic, and other cross platform tooling). this has enormous benefits to unified rendering on all platforms, maximum flexibility, and eliminating a whole class of bugs and testing done for each platform. while this is great, many scenarios we want our apps to look and feel like an android or ios app. platty allows you to render ios (cupertino) and android (material) like widgets with minimal effort and maximum control in a unified api.
no more checking for platform inside render blocks to render a cupertinobutton or flatbutton, let platty do the logic for you! want to use bottom tabs in your app that resolve to platform specific ui? no problem!
getting started of
use platty to unify render-specific apis for you. the library utilizes the buildcontext
theming apis to propagate platform
information into the widgets.
by default, all widgets conform to the default targetplatform
. it looks up the theme.of(context).platform
for its default.
also, all widgets provide a renderplatform
prop that allows you to choose which one to render (if you wish).
replace materialapp
and cupertinoapp
with platformapp
:
class myapp extends statelesswidget {
// this widget is the root of your application.
@override
widget build(buildcontext context) {
return platformapp(
title: 'flutter demo',
// specify our app theme here. we do the leg work of bridging it to cupertino.
unifiedtheme: themedata(
primaryswatch: colors.lightblue,
bottomappbarcolor: colors.red,
),
home: examplepage(),
);
}
}
platformapp
unifies all of the same properties between materialapp
and cupertinoapp
to allow both instances of widgets in the hiearchy and
switching styling based on platform.
now you replace widgets that are included in this library with their “p” counterparts:
button
/cupertinobutton
-> pbutton
flatbutton
/cupertinobutton
-> pflatbutton
appbar
/cupertinonavigationbar
-> pnavigationbar
sliverappbar
/cupertinoslivernavigationbar
-> pslivernavigationbar
slider
/cupertinoslider
-> pslider
switch
/cupertinoswitch
-> pswitch
bottomnavigationbar
/cupertinotabbar
-> ptabbar
scaffold
/cupertinoscaffold
-> pscaffold
circularprogressindicator
/cupertinoactivityindicator
-> pactivityindicator
backbutton
/cupertinonavigationbarbackbutton
-> pbackbutton
alertdialog
/cupertinoalertdialog
-> palertdialog
properties specific to a platform have a prefix
any widgets that have ios-only or android-only counterparts, they are prefixed to android
/ios
accordingly:
for example pbutton
, androidshape
applies to raisedbutton.shape
property. it does not exist on a cupertinobutton
.
however cupertinobutton
has a borderradius
and pressedopacity
. those two props become iosborderradius
and iospressedopacity
.
helpers
this library bundles a few standard functions to easily return code that is unique for each platform. instead of checking
and switching on the result of theme.of(context).targetplatform
, utilize the following methods:
specific platform instance
to have a specific p
-widget utilize a specific platform theme only, such as material or cupertino, you can wrap
it in a ptheme
instance:
ptheme(
data: pthemedata(
platform: targetplatform.android, // or ios
child: child,
),
);
or, more simply, utilize helper method:
ptheme.ios(child);
ptheme.android(child);
also, all p
-widgets and methods allow you to override the ptheme
with a renderplatform
parameter in their constructor
or calling method:
pbutton("hello android",
renderplatform: targetplatform.android,
)
this will swap the rendering over to material
widgets for this specific widget.
note: wrapping a widget with the ptheme
will propagate that instance down the widget hierarchy and is thus preferred than
manually specifying the renderplatform
for each individual widget.
creating your own platform-adapting widgets
we can extend upon the logic included in this library to build our own, powerful platform-adapting widgets.
included in the library is the platformadaptingwidget
base class, which inherits from statelesswidget
.
class sampleplatformwidget extends platformadaptingwidget {
final color color;
sampleplatformwidget({key key, @required this.color, targetplatform renderplatform}) // should allow consumers to choose targetplatform
: super(key: key, renderplatform: renderplatform);
/// render a material widget here. most material widgets require a material theme instance above it.
@override
get rendermaterial => (buildcontext context) {
return backbutton(
color: color,
);
};
/// render a cupertino widget here.
@override
get rendercupertino => (buildcontext context) {
return cupertinonavigationbarbackbutton(
color: color,
);
};
/// render a fuchsia widget here. (defaults to material)
@override
get renderfuchsia => (buildcontext context) {
return backbutton(
color: color,
);
};
}
platform-specific logic
this library comes with a few standard ways to implement behavior based on platform.
you can utilize platformwrap
, which allows you to specify a child
, and on 1 or all platforms, wrap it
with another widget:
platformwrap(
context,
child: pbutton(
padding: edgeinsets.all(0.0),
child: text(title),
color: colors.red,
onpressed: () {
navigator.push(context, platformroute.of(context, builder: page));
},
),
rendercupertino: (context, child) => padding(
padding: edgeinsets.only(bottom: 8.0),
child: child,
),
);
you can specify any of rendercupertino
, rendermaterial
, or renderfuschia
(or none).
any render methods not specified default to the child
.
also, platformselect
is a helper that enables returning different objects based on platform in a unified way.
in our platformadaptingwidget
, we utilize it to return a different widget based on platform. you can use it to return any
return type based on platform:
column(
children: [
platformselect(context,
rendermaterial: (context) => text("i am android"),
rendercupertino: (context) => text("i am ios"),
renderfuchsia: (context) => text("i am fuchsia"))
],
),
rendermaterial
and rendercupertino
are required. renderfuchsia
defaults to material.
or you can return a non-widget too:
column(
children: [
text(platformselect(context,
rendermaterial: (context) => "i am android"),
rendercupertino: (context) => "i am ios",
renderfuchsia: (context) => "i am fuchsia"))
],
),
Comments are closed.