Okay, maybe all of this still isn't quite enough for what you need. Or maybe it works, but you are building such complicated entity commands and SQL queries in Lava that it's just not performant enough. Maybe you are just far more familiar with C# so you'd rather go that way. Possibly you want to build a plugin that provides a new block type with some settings for the admin to configure and then it magically does what it does.
Let's start with the most basic block configuration:
[DisplayName( "My Custom Block" )][Category( "Rock Solid Church > Mobile" )][Description( "A custom block to do magical things." )][IconCssClass( "fa fa-square" )]publicclassMyCustomBlock:RockMobileBlockType{#regionIRockMobileBlockType ImplementationintIRockMobileBlockType.RequiredMobileAbiVersion =>1;stringIRockMobileBlockType.MobileBlockType =>"Rock.Mobile.Blocks.Content";objectIRockMobileBlockType.GetMobileConfigurationValues() {string content ="<Label Text=\"Hello World\" />";returnnewRock.Mobile.Common.Blocks.Content.Configuration { Content = content } }#endregion}
So here is what we got. We are specifying that in order for this block to render, the mobile app needs to support ABI version 1. Next we are specifying the CLR class name on the mobile app that will handle the rendering, we are going to use the Rock.Mobile.Blocks.Content block so that we can update things. This block will render a simple text label that says Hello World.
But that is rather boring. Instead, lets have it render out something a bit more expressive.
If you look very carefully, you'll notice that we prefixed the action command Search with a :. Here is the difference. Without the : prefix, the mobile block will call a single method:
That is perfectly fine and you can do it that way if you want. However, with the : prefix then it calls a method named for the Name and passes the parameters as actual method parameters. So in our case, our search method would be:
[BlockAction]publicstringSearch( string term )
Either will achieve the same result, but the latter form might be easier to read in your code - especially if you have multiple commands being handled. The return type of these methods is a simple string that contains the XAML code used to render the UI. Let's use the latter form and build our search results:
So we use the Universal Search component to get a list of all matching serving team groups. Then we loop over those results and build a stack layout of buttons. Each button will trigger the :ShowGroup command with a different GroupId value. A handler for such a command might look like:
This is a simple handler that just displays a notification on the screen stating it hasn't been implemented yet. Obviously you will want to have to actually do something. For example, you might have it display some information about the group and then display two buttons: Cancel and Join.
Dynamic Initial Content
What we described above will leave you with a block whose initial content is static, that is it never changes unless the admin deploys a new application bundle. That might work for you, but you probably want to change that content based on query string parameters and such. Let's modify our block so that it instructs the mobile application to be dynamic.
[DisplayName( "My Custom Block" )][Category( "Rock Solid Church > Mobile" )][Description( "A custom block to do magical things." )][IconCssClass( "fa fa-square" )]publicclassMyCustomBlock:RockMobileBlockType{#regionIRockMobileBlockType ImplementationintIRockMobileBlockType.RequiredMobileAbiVersion =>1;stringIRockMobileBlockType.MobileBlockType =>"Rock.Mobile.Blocks.Content";objectIRockMobileBlockType.GetMobileConfigurationValues() {returnnewRock.Mobile.Common.Blocks.Content.Configuration { Content =null, DynamicContent =true } }#endregion [BlockAction]publicobjectGetInitialContent() {returnnewRock.Mobile.Common.Blocks.Content.CallbackResponse { Content ="<Label Text=\"Hello World\" />" }; }}