Munnou Roberts

kevin Abel wrote:I'm having a lot of success working with a tutor on preply.com to learn how to write an Android Application. . . .

Hey Kevin,

It sounds like you have a clear vision for your Android app, and it’s great that you're making progress with your tutor! Here are some thoughts on your requirements:

Wake Up Periodically: You can use a Handler or AlarmManager to schedule the app to wake up every 15 minutes.

Desktop Icon: Ensure that your app is set up correctly in the manifest file, which should automatically place the icon on the home screen after installation.

Persistent Open: You can manage the app's lifecycle in the onPause and onResume methods, keeping it running in the background.

Multitasking Behavior: To control visibility in the multitasking area, use Activity flags in the intent to control how the app appears. You might consider using a foreground service for tasks that require running in the background without showing a UI.

Switch for Frequency: Implement a simple SharedPreference to allow users to set how often they want the app to wake up.

Hibernation and Processing: Utilize services that can run tasks in the background without needing the UI active.

As for battery saving, hibernating apps can help conserve power. Communicating with Android’s OS can be done through its various APIs, allowing you to access battery stats, manage background processes, etc.

Your approach to keeping things efficient and minimizing unnecessary resources is solid. Good luck with your app development!

Hi there!

Great questions! I agree that communication tailored specifically for developers and architects is a unique and much-needed focus.

Science vs. Intuition: From what I’ve gathered, Jacqui’s book seems to strike a balance between science-backed principles and experiential insights. While communication is often seen as intuitive, for developers and architects, leveraging science—such as cognitive psychology and linguistics—can really enhance clarity, especially when breaking down complex concepts. I imagine there’s a mix of both approaches to make the communication strategies more effective and relatable.

Recommended Authors: When it comes to communication for technical fields, I’d recommend books like "The Pragmatic Programmer" by Andy Hunt and Dave Thomas (they emphasize clear communication in development), or "Made to Stick" by Chip and Dan Heath, which focuses on how to make ideas more memorable. For presentations, "Resonate" by Nancy Duarte is another great resource to help tech professionals tell impactful stories.

Templates: I’d also love to hear more from Jacqui on this one! Templates for presentations and documentation would be super useful, especially if they’re optimized for technical topics. Having something that addresses the unique challenges of explaining architectures or design patterns in a concise way would be a game-changer.

Looking forward to learning more from Jacqui's insights on communication within tech spaces!

Greg Horie wrote:Hi Jacqui,

Interesting topic for a book!

I've read a few books on communications for a general audience, but I don't think I've seen one that is specific to developers and architects.

A couple questions about your book:

1) Do you base your communication principles on science or is it mostly intuitive / experiential?
2) What other communication books or authors do you recommend?
3) Do you provide any templates for presentations and/or documentation?

I look forward to reading your responses.

When transitioning from SVN to Git, it’s important to note that Git manages repositories differently. In SVN, you’re used to organizing projects in a folder/subfolder structure, but Git treats each project as a separate repository.

While Git submodules can link repositories within a parent repository, it’s not quite the same as SVN’s folder system. Submodules are designed for cases where projects are dependent on one another (like libraries), and they have their complexities (e.g., version sync between submodules).

If you want to maintain a structure similar to what you had in SVN (like an “Android” folder with subfolders for multiple projects), consider these alternatives:

Multiple Repos in One Directory: Create a parent folder on your local system (e.g., “Android”), and inside it, clone your Git repositories. Each project will have its own repository, but they will still be organized under one parent folder for convenience.

Git Submodules: If you really need to manage multiple projects inside a single repository, you can use Git submodules. Submodules allow you to keep separate Git repositories in specific directories of your main repo. Be aware though, managing submodules can be tricky if you’re not careful with updates.

Monorepo: You could also look into the monorepo approach, where you maintain multiple projects within one large repository. This can be useful if your projects are closely related, but it comes with its own challenges (e.g., scaling, dependency management).

For your use case, simply organizing repositories under a common directory without submodules might be the simplest and cleanest approach.

Let me know if you need any help setting up Git!

yaniv man wrote:Hello
I'm used to working with svn , but I wish to convert to git.

I'm used that in svn I work with folders and subfolders

say main folder is Android and under it i will place all my android projects
the next could be Java and under it my java code

but in git there is only the concept of repository, so each project gets a repository

I found in git the concept of submodule, but I do not think it is the same

How do i maintain multiple projects in a tree structure in git?