enhost Blogs

Global Reader

Welcome to the Global Reader, your window into the vibrant community of enhost BLOGS! Here, you'll find a dynamic feed of the latest posts from all our users, showcasing the diverse voices and perspectives within our Fediverse network. Explore fresh ideas, discover new writers, and engage with content that sparks your curiosity. Dive in and see what the enhost BLOGS community is creating today!

from Zachary Claret-Scott

#camping #offgrid #tech #solar #anker #outdoors

I love camping. There’s a unique peace that comes from trading city noise for the sound of wind in the trees, especially here in the UK. The goal is always to disconnect, to leave the endless notifications and digital clutter behind for a few days.

And yet, I am a complete hypocrite.

Because as much as I love the idea of being off-grid, the reality is I love having my phone charged. It’s my map, my weather station, my camera for capturing that perfect sunrise, and my podcast player for when it inevitably rains. For years, I played the game of “power anxiety”—draining small power banks, rationing my battery, and telling myself it was part of the authentic experience. It wasn’t. It was just annoying.

I needed a real, sustainable solution that could last a whole trip without me having to think about it. My list of requirements was simple: it had to power my phone, my camera batteries, and maybe a laptop for multiple days, and it needed a way to recharge itself from the sun.

After a lot of research, I found my answer: the Anker SOLIX C300X DC power station and a 100W portable solar panel.

This setup has completely changed my camping experience. The Anker unit itself holds a substantial charge (288Wh), which is more than enough to get me through a long weekend of charging phones, headphones, and camera gear. It has standard USB-A, high-speed USB-C, and 12V DC ports, so it handles everything I can throw at it.

But the real magic is the solar panel. On a reasonably sunny day, the 100W panel can fully recharge the power station, creating a virtually endless loop of free, clean energy. I can use my devices without guilt or anxiety, knowing the battery will be topped up by the time I'm back at camp in the evening.

So, am I still a hypocrite? Probably. I’m hauling a sophisticated piece of tech into the wilderness to escape technology. But this solution doesn't distract from the experience; it enhances it. It gives me the freedom to navigate, photograph, and relax, knowing the practicalities are taken care of. It’s the perfect, pragmatic compromise between being off-grid and being prepared.

 
Read more...

from The Pragmatic Pixel

Hey everyone, Jamie here.

As our applications grow, they rarely live in a vacuum. We integrate with payment gateways like Stripe, pull in data from social media platforms, react to events in services like Shopify, or track shipments with logistics APIs. A common thread in many of these integrations is the need to react to events as they happen.

Waiting for a user to refresh a page to see if their payment has been processed feels archaic. We need our systems to receive and process data in near real-time. But how do we build our Laravel applications to reliably handle this constant stream of information from external sources?

This isn't about broadcasting data from our app (we've talked about WebSockets for that), but about being an effective listener. There are a few common patterns for this, each with its own trade-offs.


Method 1: Polling (The “Are We There Yet?” Approach)

This is the simplest and most traditional method.

  • How it works: You set up a scheduled task (using Laravel's Task Scheduler and a cron job) that runs at a regular interval—say, every minute. This task makes a standard API call to the third-party service, asking, “Do you have anything new for me since last time?”
  • Pros:
    • Universal: It works with almost any API that has a standard endpoint for fetching data.
    • Simple to Implement: A scheduled Artisan command that makes a Guzzle request is straightforward to set up.
  • Cons:
    • Inefficient: The vast majority of your requests will likely come back empty, wasting both your server resources and the third-party's.
    • Not Truly Real-Time: There will always be a delay of up to your polling interval. If you poll every minute, your data could be up to 59 seconds out of date.
    • Rate Limit Danger: Polling frequently is the fastest way to hit API rate limits, which can get your application temporarily blocked.

When to use it: Polling is a last resort. Use it only when the data isn't critically time-sensitive and the third-party API offers no better alternative.


Method 2: Webhooks (The “Don't Call Us, We'll Call You” Approach)

This is the modern standard for server-to-server communication and by far the preferred method.

  • How it works: You provide the third-party service with a unique URL in your application (a “webhook endpoint”). When a specific event occurs on their end (e.g., a successful payment, a new subscription), their server sends an HTTP POST request to your URL with a payload of data about that event.
  • Pros:
    • Highly Efficient & Real-Time: Your application only does work when there's actually something new to report. The data arrives almost instantly.
    • Scalable: It scales much better than polling because it avoids constant, unnecessary requests.
  • Cons:
    • Requires Support: The third-party API must offer webhooks.
    • Security is Key: Your endpoint is publicly accessible, so you must verify that incoming requests are genuinely from the third-party service. Most services do this by including a unique signature in the request headers, which you can validate using a shared secret.
    • Initial Setup: It requires a bit more setup than a simple polling command.

When to use it: Almost always, if the service provides it. This is the gold standard for event-driven integrations.


Method 3: WebSockets (The “Dedicated Hotline” Approach)

This is the least common method for this specific use case but is worth knowing about.

  • How it works: Instead of them calling you (webhook) or you calling them (polling), your application would establish a persistent, two-way WebSocket connection to their service. They would then push data down this open connection as events happen.
  • Pros:
    • The Fastest: This is the absolute lowest-latency, most real-time option available.
  • Cons:
    • Rarely Offered: Very few standard third-party APIs (like payment gateways or e-commerce platforms) offer a public WebSocket interface for this kind of integration. It's more common for real-time financial data feeds or live sports tickers.
    • Complexity: Managing a persistent client connection from your backend, including handling disconnects and retries, adds significant complexity to your application.

Pragmatic Implementation in Laravel: Queues are Essential

Regardless of how the data arrives (polling or webhook), the next step is critical: process it asynchronously.

Never, ever perform complex logic directly in the controller that receives a webhook. A webhook request should be acknowledged as quickly as possible with a 200 OK response. If you try to process the data, update your database, and call other services during that initial request, you risk timeouts, which can cause the third-party service to think your webhook failed and retry it, leading to duplicate data.

The Golden Rule: Acknowledge, then Queue.

  1. Create a dedicated route and controller for your webhook endpoint (e.g., Route::post('/webhooks/stripe', [StripeWebhookController::class, 'handle']);).
  2. In the controller:
    • Verify the webhook signature to ensure it's authentic.
    • Immediately dispatch a Job onto your queue with the webhook payload.
    • Return a response()->json(['status' => 'success'], 200);
  3. Create a Job Class (e.g., ProcessStripeWebhook.php).
    • This job will contain all the heavy logic: parsing the payload, creating or updating models, sending notifications, etc.
  4. Run a Queue Worker: Have a queue worker process (php artisan queue:work) running on your server to pick up and execute these jobs in the background.

This pattern makes your webhook integration incredibly robust. It can handle spikes in traffic, and if a job fails for some reason, Laravel's queue system can automatically retry it without losing the original webhook data.


Choosing the right method to ingest real-time data is about understanding the tools offered by the third-party service and the needs of your application. But no matter how the data arrives, handling it with a resilient, queue-based architecture is the key to building a stable and scalable system.

Cheers,

Jamie

 
Read more...

from Zachary Claret-Scott

#gitea #git #selfhosted #devops #coding #php

For years, my code has lived on GitHub. It’s the industry standard for a reason: it’s robust, collaboration is seamless, and it’s the heart of the open-source community. For my public and professional work, it's indispensable. However, for my dozens of private projects, experiments, and snippets, I've always felt a slight disconnect. I was relying on a third-party service for code that is deeply personal or in its very early, chaotic stages.

The main issue wasn't trust, but sovereignty and simplicity. I wanted a space that was entirely my own, without the public-facing pressure or the feature bloat of a massive platform. I considered self-hosting a full GitLab instance, but much like my experience with Mastodon, it felt too resource-heavy for my needs. I just wanted a fast, private, and reliable Git server.

That’s when I turned to Gitea.

Gitea is a lightweight, open-source Git server that's incredibly easy to set up. It's a community fork of Gogs and is written in Go, which means it runs as a single binary and has remarkably low resource requirements. I was able to get it running in a Docker container on my own server in under 30 minutes.

The power of having a personal Gitea instance is threefold:

  • Total Privacy: All my code, commit history, and issues are on my own hardware. There's no question about data ownership or who might be scanning my repositories.

  • Blazing Speed: Pushing and pulling from a server on my local network (or a close-by cloud server) is noticeably faster than going through a major commercial service.

  • Simplicity & Control: The interface is clean and familiar, providing all the core features you’d expect (repos, pull requests, issue tracking, wikis) without the overwhelming complexity of larger platforms. It's everything you need and nothing you don't.

Setting up Gitea has given me the perfect private workspace. It complements my public work on GitHub while providing a secure, fast, and fully-owned home for all my personal development. For any developer who values data ownership and a streamlined workflow, it’s a self-hosting project I highly recommend.

 
Read more...

from The Pragmatic Pixel

Hey everyone, Jamie here.

It's been a few weeks since my last post, and for good reason. The past month has been a whirlwind of boxes, goodbyes, and new beginnings. I've made another significant move, but this time it wasn't to a new company, but to a new (old) location: I've moved back to my hometown.

After years spent in and around the gravitational pull of major tech hubs, this shift has been more than just a change of scenery. It's prompted a lot of reflection on the different “flavours” of tech life in the UK, and the contrast between the bustling city hubs and the quieter, but no less important, regional tech communities.


The Buzz of the Tech Hub

We all know the picture of the major tech hub—think London, Manchester, or Bristol. It's a world of constant motion.

  • The Scale: Everything is bigger. The companies are global names, the user bases are in the millions, and the engineering challenges are often about operating at a massive scale.
  • The Community: There are meetups for every conceivable niche, from esoteric programming languages to hyper-specific DevOps tools. You're surrounded by a huge talent pool, and opportunities feel endless.
  • The Roles: The work is often highly specialized. You might be a “Backend Performance Engineer” focusing solely on optimizing one part of a huge system, or a “Design System Specialist” working on a component library used by hundreds of other developers.

The energy is undeniable. It’s a place where you can get exposure to cutting-edge tech and massive, complex problems. But it comes with a well-known trade-off: a high cost of living, intense competition, and a pace that can sometimes feel relentless.


The Heartbeat of the Regional Scene

Moving back home has re-acquainted me with a different, but equally valid, tech reality. The rhythm is different here.

  • The Scale: The companies are often small-to-medium-sized businesses, digital agencies, or established local firms undergoing digital transformation. The problems aren't necessarily about handling a million concurrent users, but about delivering direct, tangible value to a specific customer base.
  • The Community: It's smaller and more tight-knit. You're more likely to know a significant portion of the local developer community by name. Meetups might be more generalist (“PHP North,” “Digital Lincoln”), but they foster a strong sense of local camaraderie.
  • The Roles: The work often requires you to be more of a generalist, a “pragmatic polyglot.” You might be handling the Laravel backend, dabbling in the Flutter app's UI, and having a direct conversation with the business owner all in the same day. Your impact feels incredibly direct and immediate.

The work can feel more grounded. You're not just optimizing a microservice; you're building the entire system that helps a local business thrive.


The Great Equalizer: Remote Work & The Hybrid Reality

Of course, the world has changed. The rise of remote work has blurred these lines significantly. It's now entirely possible to live in a quiet market town while working on a massive, globally-distributed team for a London-based company. This has been a fantastic democratizing force for talent across the UK.

However, it hasn't erased the distinction entirely. Many companies are now settling into a “hybrid” model, requiring office attendance once or twice a week. This reinforces the hub-and-spoke model, keeping the gravitational pull of the big cities alive.

Even in a fully remote role, there's something to be said for local connection. Being able to grab a coffee with another developer who lives nearby, even if you work for different companies, provides a sense of community that a video call can't fully replicate.

A Deliberate Choice

For me, this move wasn't a retreat from the “big leagues.” It was a deliberate choice about quality of life, community, and the type of impact I want to have. There's a unique satisfaction in being part of a growing local tech scene, where you can make a visible difference and help shape its identity.

There's no right or wrong answer. The high-octane environment of a tech hub is an incredible place to learn and grow, especially early in a career. But the focused, impactful work and tight-knit community of a regional tech scene offer their own deep rewards. It's a reminder that a fulfilling tech career isn't tied to a specific postcode.

What's your local tech scene like? Are you in a major hub, a regional town, or somewhere in between? I'd love to hear your perspective in the comments.

Cheers,

Jamie

 
Read more...

from The Pragmatic Pixel

Hey everyone, Jamie here.

Since starting my new role, I've been thinking a lot about the environments we build software in. It's not just about the code we write, but the entire rhythm and process surrounding it. One of the biggest factors that dictates this rhythm is the size of the organisation.

Working in a small startup or a solo venture is like captaining a speedboat. You can turn on a sixpence, change direction in an instant, and feel the spray in your face. Working in a large, established enterprise is like steering a supertanker. It's immensely powerful and stable, but changing course requires planning, coordination, and a lot of time.

Having experienced both ends of the spectrum here in the UK, I wanted to share some thoughts on these two very different worlds.


The Speedboat: Small Companies & Startups

This is the world of “move fast and break things” (though hopefully, you fix them just as fast). It's often characterized by small, cross-functional teams, or even solo developers, where everyone wears multiple hats.

The Vibe:

  • Direct Impact: You can have an idea in the morning, code it in the afternoon, and deploy it before you log off. The feedback loop is immediate and incredibly satisfying.
  • Minimal Process: Forget Change Advisory Boards. A “change request” is often just a quick chat over Slack or a new ticket in Jira. The priority is getting features out to users and iterating based on their feedback.
  • High Ownership: You're not just a coder. You're often part of the product, support, and QA process. You feel a deep sense of ownership because your fingerprints are all over the entire product.

The Trade-offs:

  • Chaos can reign. Without formal processes, it's easy for things to get messy. Documentation can be sparse, and tech debt can accumulate at an alarming rate.
  • You are the safety net. There might not be a dedicated QA team. If you push a bug, you're likely the one getting the alert and fixing it late at night.
  • It can be a high-pressure environment, constantly balancing speed with the need for a stable product.

This environment is thrilling and perfect for those who love agility and seeing their direct impact on a product's growth.


The Supertanker: Large Enterprises & Corporations

This is a world of structure, process, and specialization. It's built around mitigating risk and ensuring stability for a large user base or critical business operations.

The Vibe:

  • Structured & Deliberate: There are well-defined processes for everything. A new feature will go through product management, design, development, multiple stages of QA (including regression and performance testing), security reviews, and finally, a scheduled release window.
  • Specialized Roles: You're part of a larger machine. There are dedicated DevOps engineers, database administrators, QA analysts, and project managers. Your job is to focus purely on development, and you have experts to rely on for other areas.
  • Scale & Stability: The “blast radius” of any change is huge. A bug could impact thousands, or even millions, of users or financial transactions. Therefore, every change is meticulously planned and tested.

The Trade-offs:

  • The pace can feel slow. That “quick text change” might take two weeks to get to production because it has to follow the established release train. Bureaucracy is a real factor.
  • Your individual impact can feel diluted. You're a vital cog, but just one among many. It can sometimes be harder to see the direct line from your code to the end-user's happiness.
  • You have less freedom to choose your tools or make architectural decisions on the fly.

This environment is excellent for those who appreciate stability, want to work on large-scale problems, and value having a structured process and a deep support system of specialists.


Why the Difference? It's All About Risk

Neither approach is inherently “better”—they are simply different solutions to different problems.

  • The Speedboat optimizes for speed and learning. Its biggest risk is failing to find a market or running out of runway. It needs to move fast.
  • The Supertanker optimizes for stability and predictability. Its biggest risk is breaking a system that already works for a massive user base. It needs to be cautious.

My journey has taught me to appreciate both. There's an undeniable thrill in the agility of a small team, but there's also a deep professional satisfaction in contributing to a large, stable system and learning from specialists in a structured environment.

Understanding which rhythm suits you best at a given point in your career is key. Sometimes you want to race, and sometimes you want to sail a steady course.

What's your experience been like? Are you on a speedboat or a supertanker? I'd love to hear your thoughts in the comments.

Cheers,

Jamie C

 
Read more...

from The Pragmatic Pixel

Hey everyone, Jamie here.

As developers, we tend to build our “homes” in certain frameworks and ecosystems. For me, and for much of this blog, that home has been Laravel. I appreciate its elegant syntax, its “batteries-included” philosophy, and the sheer speed at which you can build robust, modern applications. It's a fantastic tool that I know and love.

Recently, however, I had the opportunity to dive deep into a project built purely on Symfony. It wasn't just about using a few Symfony components under the hood (which Laravel does extensively), but about working within the complete Symfony framework, with its own conventions, structure, and mindset.

It was a fascinating experience that felt like visiting a well-designed, but very different, city. It made me appreciate not only what Symfony does so well but also gave me a fresh perspective on why Laravel works the way it does.


The Initial Shock: “Where's the Magic?”

My first few hours with the Symfony project were a lesson in humility. As a Laravel developer, you get used to a certain amount of “magic” and convention. Things just work.

  • Eloquent vs. Doctrine: I found myself missing the simplicity of Eloquent. In Symfony, the default ORM is Doctrine. It's incredibly powerful and robust, but it's also more verbose. Defining entities, repositories, and mappings felt more deliberate and required more boilerplate than simply creating a new Laravel model.
  • Configuration Over Convention: Laravel famously favors convention over configuration. In Symfony, the opposite is often true. I spent a good amount of time in YAML files (services.yaml), explicitly defining services and their dependencies. My first reaction was, “Why do I have to wire all this up myself?”
  • No Facades, Just Services: There are no global helpers like auth() or cache(). There are no facades providing a simple, static-like interface to underlying services. Everything is a service, and if you want to use it, you must explicitly inject it into your class's constructor.

It felt like the framework was forcing me to be incredibly explicit about every single thing I was doing.


The Slow Appreciation: The Power of Explicitness

After the initial friction, something started to click. The very things that felt like hurdles at first began to reveal their purpose and power.

  • Dependency Injection is a First-Class Citizen: Because you have to inject every dependency, your code becomes incredibly clear. You can look at any class's constructor and know exactly what its dependencies are. This makes the code highly predictable, decoupled, and exceptionally easy to test. You're not guessing where a service comes from; it's right there.
  • Unmatched Flexibility: Symfony feels less like a framework you build inside of, and more like a set of high-quality components you build your application with. You have complete control. You can swap out almost any part of the system with your own implementation. This level of flexibility is fantastic for large, complex, or long-lived enterprise applications where requirements are unique and evolving.
  • Stability and Predictability: The lack of “magic” means there are fewer surprises. The call stack is often easier to trace. You can follow the path from configuration to instantiation to execution without the framework doing things behind a curtain. This can be a huge advantage when debugging complex issues.

What I Missed From Laravel: The Joy of Convention

As I grew to appreciate Symfony's architecture, I also found myself missing the sheer developer experience and rapid development cycle that Laravel provides.

  • Eloquent's Elegance: For all of Doctrine's power, I missed the beauty of defining a hasMany relationship in a single line and chaining query builder methods with such ease. For 90% of standard CRUD and API tasks, Eloquent's speed and readability are hard to beat.
  • The “Batteries-Included” Ecosystem: Laravel's first-party packages like Sanctum, Telescope, and Sail create a seamless, cohesive development experience. Setting up API authentication with Sanctum, for example, is a beautifully simple process. In Symfony, you're more likely to be assembling and configuring different bundles to achieve the same result.
  • Artisan and the make Commands: I missed the convenience of php artisan make:model -mcr. Laravel's command-line tools are tailored for rapid scaffolding and reducing boilerplate, which keeps you in the creative flow.

The Right Tool for the Job

My time with Symfony didn't make me think Laravel is “better” or vice-versa. It solidified my belief that they are two different tools with different philosophies, both built on the same excellent foundation of modern PHP.

  • Symfony feels like a meticulously organized workshop full of high-end, individual power tools. It gives you the power and flexibility to build anything, but it expects you to be a skilled craftsperson who knows how to assemble them. It shines for complex, bespoke, long-term projects.
  • Laravel feels like a state-of-the-art, all-in-one workstation. It has pre-configured tools, sensible defaults, and clever jigs that let you build common things incredibly quickly and elegantly. It shines for rapid application development, APIs, and a huge range of web applications.

Ultimately, working with Symfony made me a better PHP developer. It forced me to engage with concepts like the service container and dependency injection on a much deeper level. And when I returned to a Laravel project, I had a newfound appreciation for the thoughtful conventions and the “magic” that lets me focus on building features so quickly.

What are your experiences moving between the two frameworks? I'd love to hear your thoughts in the comments.

Cheers,

Jamie C

 
Read more...

from The Pragmatic Pixel

Hey everyone, Jamie here.

Following on from my last post, I've been really touched by the messages of support and the shared stories about navigating the tech job market. There's a huge amount of excitement that comes with accepting a verbal offer for a new role. It’s the culmination of weeks, sometimes months, of interviews, technical tasks, and conversations. The natural instinct is to rush to your current boss, hand in your notice, and start the countdown to your next chapter.

But I want to talk about the most critical, and often overlooked, step in this entire process: the pause. The deliberate, professional, and absolutely essential moment between the “Yes, I'd love to accept!” and “Dear Boss, please accept this letter as my formal resignation.”

I'm talking about waiting for the signed contract.


A Verbal Agreement is Built on Good Faith. A Contract is Built on Certainty.

Let's be clear: in the vast majority of cases, a verbal offer is made in good faith. The company wants you, you want them, and everyone is excited. But good faith doesn't protect you if things go wrong.

A verbal offer is not a legally binding employment contract. It's a statement of intent. Until you have a written document, signed by both you and an authorized person at the new company, you are in a professional no-man's-land.

Here’s why that’s a risk you should never take:

  • Details Get Lost in Translation: Was the salary £X, or was that the “total compensation package” including a potential bonus? Is the start date flexible? What's the exact job title? Details discussed over a phone call can be easily misremembered or misinterpreted by either side. The contract solidifies these details in black and white.
  • Internal Situations Change: This is the big one. Between a verbal offer and your start date, anything can happen. Budgets can be unexpectedly frozen, the project you were hired for can be de-prioritized, the hiring manager might leave, or a last-minute internal candidate might emerge. A verbal offer can be rescinded with a difficult phone call. A signed contract makes this significantly more complicated and less likely.
  • It's Your Only Safety Net: Imagine resigning from your stable job, only to have the new offer withdrawn a week later. You're left with no job and no recourse. It's a nightmare scenario, and while it's not common, it happens. The contract is your safety net.

What to Check Before You Sign (and Resign)

When that PDF lands in your inbox, don't just skim to the signature line. Read it carefully. You're checking that it matches your discussions.

  • The Core Details: Salary, job title, start date, and your primary place of work.
  • Notice Period: What's required from you if you leave, and what's required from them? Does this change after a probationary period?
  • Restrictive Covenants: Pay close attention to these. Are there non-compete clauses that could limit your future employment? Non-solicitation clauses? Understand what you're agreeing to.
  • Benefits: Check that key benefits like holiday entitlement, pension contributions, and any mentioned health or insurance plans are documented.
  • Job Description: Does the summary of your role and responsibilities align with what you discussed in the interviews?

If there are any discrepancies, now is the time to raise them politely. It's much easier to clarify a detail before you've signed than to dispute it later.


The Golden Rule

It's so simple, yet so important that it's worth stating plainly:

Never, ever resign from your current position until you have a signed, written employment contract from your new employer.

Chasing for it isn't being pushy; it's being professional. A simple, polite email is all it takes:

“Hi [Hiring Manager/HR Contact], I'm incredibly excited to have accepted the offer and am really looking forward to joining the team. Just checking in on the written contract so I can get that signed and then hand in my notice at my current role. Please let me know if you need anything else from me in the meantime.”

This shows you're organised and diligent—qualities they hired you for in the first place. Any reasonable employer will understand and respect this completely. If they pressure you to resign before providing a contract, that itself is a major red flag.

Taking that small pause to ensure your next step is secure doesn't diminish the excitement of a new role. It protects it. It allows you to hand in your notice not with a leap of faith, but with the confidence and certainty that you deserve.

Cheers,

Jamie C

 
Read more...

from Virtus Computing

This tutorial continues from the last one in the NotePad app set Basic4Android: Notepad – Part1 (Designing). In this tutorial i am taking the design and adding code to make the app load the text from files and display it in one of the four slots.

App start up

When the app starts up we are going to load in the design with the buttons and the text box in. We are also going to put things into the menu. All of this start up code goes inside the Activity create sub.

Sub Activity_Create(FirstTime As Boolean)
    'Code to run here
End Sub

Loading the layout

First of all loading the layout, all this is done with one line of code which just loads the file we saved in the first tutorial. We made main.bal in the first tutorial and now we are displaying that.

Activity.LoadLayout("main.bal")

Adding menu items

Adding menu items is very simple, we are going to add three menu items Clear, Save, Exit. These will only appear when the menu button is pressed so it saves on screen space. It is one line of code for each menu item. We are only using text items so the line of code is this:

Activity.AddMenuItem("title", "event")

The title is what you want the menu button to say example “Clear” and the event is where you want to run the code example “clear” which would run the sub “clear_Click”. We are adding the three menu items below:

	Activity.AddMenuItem("Clear", "clear")
	Activity.AddMenuItem("Save", "save")
	Activity.AddMenuItem("Exit", "exit")

Loading the slots

When each slot button is pressed two things will happen.

  • The data for that slot will be loaded and displayed.
  • The strings will be changed so that when saved the data is saved to the right slot. We will do the second one first as it is the simplest to do and requires only a few lines of code. First we need to set up the variable to store which slot is open. To do this we Dim the string in the Globals sub. Inside there under the setting up of the buttons and text box add the two lines. Dim slot As String slot = "0" That line lets the program know that if slot is used that it is a bit of data. Right under that line we are going to set slot to 0. This is because we don’t want bugs when a user clicks save straight away. Now we need to put a bit of code into each button so that the slot string changes. For example the button for slot 1 will be: Sub slot1_Click slot = "1" End Sub This needs to be added to all of the other subs, they should have been generated in the first tutorial, so all you need to do is add the second line to each sub. Remember to change the number so that slot2_Click contains slot = “2″ and so on.

Now we need to load the data for each slot. This is very simple to do we just need to load a text file when each button is clicked. this is done in one line, but we are going to make sure the file is there before opening to stop any errors. So under the line above we need to check for a file like this:

If File.Exists(File.DirInternal,"notepadapp-slot" & slot & ".txt") Then
    	notepadbox.Text = File.ReadString(File.DirInternal, "notepadapp-slot" & slot & ".txt")
	ToastMessageShow("Data loaded for slot " & slot & ".", True)
Else
	notepadbox.Text = "There is no data for slot" & slot
	ToastMessageShow("No data loaded for slot " & slot & ".", True)
End If

That code checks to see if the file notepadapp-slow1.txt is there, if it is then it will load the data into the text box. If not then it will display a message. The slot can still be loaded without there being data, and when it is saved for the first time it will create that file for the next time. That code needs to be put in all the four slot buttons and does not need to be modified.

Saving the slots

saving the slots is very easy, it is again just one line of code to do so. You will need to create a new sub like below with the following code inside. It can be anywhere in the code i added it at the bottom.

Sub save_click
	File.WriteString(File.DirInternal, "notepadapp-slot" & slot & ".txt", notepadbox.Text)
	ToastMessageShow("Data saved for slot " & slot & ".", True)
End Sub

The Clear button

The clear button just resets the files to default and removes all the data from it, it is only a few lines of code. it sets the text box to having no data and then writes that to the file. A new sub is need for the clear button just like with save.

Sub clear_click
	notepadbox.Text = "There is no data for slot" & slot
	File.WriteString(File.DirInternal, "notepadapp-slot" & slot & ".txt", notepadbox.Text)
	ToastMessageShow("Data deleted for slot " & slot & ".", True)
End Sub

The exit button

The last button in the menu is the exit button, this is to fully stop the program and not leave it running in the background. I like this in my apps so i can close them and speed up my phone and save battery. The code is very simple and uses a new sub.

Sub exit_Click
	Activity.Finish
	ExitApplication
End Sub

Finishing off

The app now fully works, there is one last thing i want to do to make it work better across phones with big screens. There are many things that can be edited along with colors designs, and loading the slots in a list box. This is the trick i used to make it better on bigger phones it just makes the text box adjust to the screen size, this code goes right after the menu code near the top.

notepadbox.Width = Activity.Width
notepadbox.Height = (Activity.Height - 50)

Done

That is now the app working fully. There is many things that can be added and made better, but this is a working android program that uses files to store data.

Screenshots

notepadappscreenshot (1) notepadappscreenshot (2) notepadappscreenshot (3)

End result

The app on Google Play

Written by Zachary.

 
Read more...

from Virtus Computing

In this set of tutorials i will go through how to make a notepad app. A very simple one with 4 slots and a text box to edit the text in them slots. It will save the data on the SD card if there is one and on the phone if not. I will have settings to change fonts and colours for each slot. This tutorial will be split into 2 parts:

  • Designing
  • Saving and loading slots

After that i will go on to add more functions and explain more things that can be done in B4A and how to use them.

Application settings.

First of all open up B4A and click save, this is because you can not use the GUI designer without saving it first. I recamend making a new folder to save it in like NotepadApp. Put the file name as notepad and click save. Saving the Notepad app.

When it is saved we can start to set up the settings of the app, Like the Name, Icon and Version number. Got to Project and select Choose Icon. Then select the icon from your computer. I am going to use a simple one i found on the internet. (You can download it here)

The next thing we want to edit is Package Name, this is a unique field that identifies your app and will be different from all other apps. Most of the time Developers put this to:

*appname*.*developername*.*companyname*

That is because it has to conation at least two words with a dot between them, it must all be lowercase. In this tutorial i am going to set mine to notepad.virtuscomputing.tutorial. You may use that name as well.

The last one we are going to change today is the Application Label, This is the name of your app and the one that is displayed on the app draw, in your settings, and on the top of the app. I set mine to NotePad.

Designing.

Now we can open up the designer and start to build the GUI. It will be one big Text-box with a tab host along the top. There will be a menu with a Save, Clear and Exit buttons on it. This will be most of the app interface for now. Open up the designer and click Add View then Edit Text, Drag it around the form with the square in the corners. It needs to fit the entire screen, starting from 50 from the top going all the way down to the bottom. You can then add 4 buttons and spread them across the gap left in the top. To make our code easy to read and understand rename the buttons to slot1, slot2, slot3, slot4. And the textbox to notepadbox. This is done by selecting the item, and looking at the top of the list of propities and changing the Name field.

Notepad Design Form

You should end up with something like the form above. At this point you can move thigs around to how you want them to be. Then click File –> Save, and name it main. Once this is done there is one more thing we need to do before starting to code the app. Select Tools –> Generate Members. When the new form opens up Select all views to select all the boxes. On slot1, slot2, slot3, and slot4 open then with the little + to one side and select the box for Click. Once this is done for all of them press Generate Members.

Notepad Generating Members

This inserts all the code into the file to make all them forms appear That is the last of the designing for now. You can move things around in the designer and make them look how you want.

All the code is in Basic4Android: Notepad – Part2 (Code)

Written by Zachary.

 
Read more...

from Virtus Computing

To make the test application we are just going to do the hello world app. This just prints the words hello world on the form to prove that it works. When you clickt he text hello world it will change, just to show how events are handled.

To start when you open Basic4Android it gives you a set of code already. We will be using this code to click Save and select where you want to save the project and all its files. I recommend making a new folder just for the project. Then name the project what you want. here is it called Testing for Tutorial then click save.

After we have save the project the file is created with a .b4a on the end (as seen in the picture above). Once we have saved we can now open up the designer, Click Designer on the menu bar. Two new windows will open up like the below. One of them (The bigger one) Is the control properties window. The other is the Designer.

You can now click Add New and then Label. It inserts the label onto the form and called it Label1 You can drag this around and re size it if you want to (When the item is clicked on the properties window you can change the test font and size. You can input the text there, but we are going to do it programmatic for now. Right click on the label and hover over Generate then Dim Label1 As Label, Then do that again but select Click this time.

Once that has been done we can save the layout, Click File then Save and give the layout a name of main and click Ok. The window should look like the one below.

Once we have done that we can close the designer and begin on the code. There is not allot of code for this program. The first bit it to load the label one we start the program. And then to print text into the label.

Sub Activity_Create(FirstTime AsBoolean)
Activity.LoadLayout("main")
'The line above is to load in the layout we made, remember the name "main"
Label1.Text = "Hello World"
'The line above print the text "Hello World" onto label1
End Sub

The code above should replace the code already in the Activity_Create. The code below is to change the text when the user clicks on the label.

Sub Label1_Click
Label1.Text = "I've been clicked"
'The line above print the text "I've been clicked" onto label1
End Sub

The code above should replace whats in Label1_Click. When the activity is started it calls the first bit of code which sets up the windows and loads in the forms. It then prints the first bit of text to the label. When the label is clicked it calls the second bit of code which changes the text. Make sure to save at this point!

Testing on a android device

If you are using a physical android device then connect it to the same WiFi to the computer(this is the way i do it) Download the Program to your phone (The Basic4Android Bridge linked in the top) Then run it, it needs to configuration and should have some buttons on there. Click the button that says Start – Wireless, it should then start the service. It will say “waiting for connections” when it is ready. Then go to your computer and in basic for android go to Tools then B4A Bridge then Connect – Wireless.

It will prompt you for an IP, This is displayed on your phone and should be something like 192.168.1.68. Type it in and click connect.

If it has worked your phone will say connected.

If it has worked then you can now click the Blue Arrow on basic for android and it will compile the application. When it is done your device will prompt you to install the app automatically. But the APK file is in /objects/Testing for Tutorial.apk so you can send it to your device another way.

Installing the app on the phone. You need to click Install at the first screen, It will then install the application

After it has installed you can Open or Done, You want to open it and make sure it has worked. If you click the label the text will change.

Make sure to press Stop on B4A Bridge to save your battery when you are done.

Written by Zachary.

 
Read more...

from Virtus Computing

Basic4Android is a very useful program to write applications for the android operating system. It runs on windows and has a very similar feel to VB.net. The IDE is very clean and easy to use. And with the remote bridge software you can install the applications straight to a mobile device.

Getting all the files.

Java JDK 7 (32-bit or 64-bit)

http://www.oracle.com/technetwork/java/javase/downloads/jdk7u9-downloads-1859576.html

Android SDK

http://dl.google.com/android/installer_r20.0.3-windows.exe

Basic4Android trail setup (If you have bought it then use the setup sent in the email)

Enterprise Standard (Trial)

Basic4Android Bridge (From the market onto your phone – Optional)

https://play.google.com/store/apps/details?id=anywheresoftware.b4a.b4abridge (http://vcurl.co/?i=f2ea)

Installing

Java

Installing java first as everything needs it. To install java i find it is best to uninstall any Java things you have previously installed. That way you are starting from scratch. Once it has been uninstalled run the Java setup program and install Java to the default place. (The Java JDK development tools will still work for any other java resource. including your browser) Once the Java install has completed do not restart your computer.

Android SDK

Installing the android SDK is a little more complicated. Run the setup and follow through the instructions. Install it all to the default place after the install has completed go to your Start menu and find the “SDK Manager” run that and wait while it starts up (This can take some time). Once it has started up wait for it to refresh the package lists. One it has done select. Android 4.1 (And all that’s inside it) Then click Install packages… You will have to select Agree and Install. Then the bar at the bottom will show the progress of the installation.

Basic4Android

One everything else is installed, i recommend you have restarted before installing Basic4Android. If you are installing the trail then you need to run the file you downloaded at the top. If you have bought it then download the file from your emails and download that file to install. When running the file just install the the default places.

Configuration

When all programs are installed, it is time to configure Basic4Android to work with the Android SDK, and Java JRE. Doing this is very simple and it is only inputting two file paths. One for the javaac.exe and the other for android.jar. To do this open up Basic4Android, Once it has loaded (you will have to select Trail, unless you have a key in which case select the key). Go to Tools then Configure Paths

After you click that you are presented with the window below. You need to locate the two files it says about. It has a location of where they should be but i found that it is not there anymore. Click browse to find the files. Which for me are in these locations (Just remember to change to your username, and correct versions.)

C:\Program Files\Java\jdk1.7.0_07\bin\javac.exe

C:\Users\Zachary Claret-Scott\AppData\Local\Android\android-sdk\platforms\android-16\android.jar

The Additional Libraries folder is if you want to specify an extra folder for it to look for them. It already looks in the program files for them and that’s were we will place them. I will cover libraries in other posts but they allow you to do more stuff like tracking the usages of an app, or talk to ftp.

In the next Guide i will Talk about how to make a application. (Here)

Written by Zachary.

 
Read more...

from keleven

Hopefully this blog will chart my motorbike rides on my trusty Royal Enfield 350 Classic.

I might add other things that I find interesting, then I might not.

 
Read more...

from Zachary Claret-Scott

#music #spotify #lastfm #data

I’ve been tracking my music listening habits for decades on last.fm ever since my dad introduced me to the platform – it’s great to see what music I listened to overtime.

I used to use last.fm daily to find new music by exploring radios, in a time before streaming when ripping mp3s of disk (or online) was king it was the best way to find new music. Once Spotify took over I dumped my local music collection and exclusively listened to streamed music, I had my last.fm connected and mostly ignored it while it silently collected my data.

I’m not sure when last.fm changed but it’s a far throw from its glory days now and it’s hard to see really simple stats about my listening history without signing up for a pro membership. Recently I found an alternative which is exclusive to Spotify called YourSpotify. It is self hosted and pulls recent listening data in real time from the Spotify API but requires a data export from Spotify (which takes up to 30 days) for full historic listening data.

Cover Image

 
Read more...

from Zachary Claret-Scott

#services #selfhosted #homelab

I have wanted to host my own fediverse/activity pub compatible server for a while – however I felt running a full on Mastodon server was to heavy for my use case. And other options seemed to take a bit too much effort to host for my liking.

I had all but given up until I came across Write Freely which is a blog focused platform that just so happens to share posts via activity pub. Setting it up was super simple as a single docker container and it supports single user mode, or multi user mode with very basic permissions.

I have put it up on a spare domain which I can use as my federated username @prra.xyz because it is generic I can also use it as a social media post engine for all my company accounts.

Cover Image

 
Read more...